Multithreading

[Milan Babuskov-4]

Hi all,

I'm just reading Firebird 2.5 release notes, and this caught my attention:

"The client libraries, including the embedded one, can now be used in
multi-threaded applications without any application-level
synchronization."

This makes me wonder whether we could get much easier multi-threading
support if we decide not to support earlier Firebird versions (it is
known that client is thread safe in some architecture even for some
older versions)?

It basically means we could use a single connection for each database
from different threads. It seems to me that it would be much easier to
spawn worker threads and code would be less complex.

Any thoughts?

--
Milan Babuskov
http://www.flamerobin.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flamerobin-devel mailing list
Flamerobin-devel@...
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel

[Michael Hieke]

Milan,

Milan Babuskov wrote:

> It basically means we could use a single connection for each database
> from different threads. It seems to me that it would be much easier
> to spawn worker threads and code would be less complex.

I'm not sure how much that would help us.  The biggest problem seems to
me the necessary synchronization inside of FR.  Also (as I stated many
times before) FR source code doesn't seem to be in a state to be
expanded much further.

And with large-scale changes to the code, do you really think that
having a connection object inside each worker thread is that much of a
burden, given that most of the other problematic issues remain
essentially unchanged?
Or do you think about multi-threading the current FR source code?

Thanks

--
Michael Hieke


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flamerobin-devel mailing list
Flamerobin-devel@...
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel

[Milan Babuskov-4]

On Mon, Jul 21, 2008 at 9:05 AM, Michael Hieke <mghie@...> wrote:
> I'm not sure how much that would help us.  The biggest problem seems to
> me the necessary synchronization inside of FR.  Also (as I stated many
> times before) FR source code doesn't seem to be in a state to be
> expanded much further.

True, true.

> And with large-scale changes to the code, do you really think that
> having a connection object inside each worker thread is that much of a
> burden, given that most of the other problematic issues remain
> essentially unchanged?

I don't know, I was just 'thinking aloud'

> Or do you think about multi-threading the current FR source code?

I thought about both the new code and the old code. The way I see it:
the way things are now, if multithreading is not possible in the old
code, our path would look like this:

1. Fix all the minor glitches are finish with the old code base.
Whether we will call it 1.0 or not is up for discussion.
2. Stop developing new features in old code base (only critical bug
fixes) and move development to the new base with aim of creating
FlameRobin 2.0 at some point in (distant?) future

The main problem is: resources. If we continue at current pace, it
will be a long time before 2.0 reaches the feature set of current
0.8.x code. In the meantime, users will want a tool that works with
Firebird 2.5 and maybe even Firebird 3.0 if it gets released before
we're done.

That's why I was looking at both options:

a) to see whether we can get cheap multithreading support in old code
base before deciding to abandon it
b) to see whether we can get cheap MT support in new code to avoid complexity

Looks like changes in FB 2.5 don't really help us much.

--
Milan Babuskov
http://www.flamerobin.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flamerobin-devel mailing list
Flamerobin-devel@...
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel

[Michael Hieke]

Milan Babuskov wrote:

> The main problem is: resources. If we continue at current pace, it
> will be a long time before 2.0 reaches the feature set of current
> 0.8.x code.

That's true.  Development will most probably be even slower, because
until now you simply implemented the features you needed for FR, while
from here on that's not strictly necessary any more - FR 0.8 is already
there to do the work...

> In the meantime, users will want a tool that works with Firebird 2.5
> and maybe even Firebird 3.0 if it gets released before we're done.

Agreed.

> a) to see whether we can get cheap multithreading support in old code
> base before deciding to abandon it

I haven't done anything on the branch myself, for ages, and I doubt that
there is any chance of this happening in the near future.  So unless
somebody else takes the code and runs with it, abandoning current FR
would be foolish.
OTOH: The more time is spent on new features of current FR, the less
probable it is that there will *ever* be code that supplants it.

> b) to see whether we can get cheap MT support in new code to avoid
> complexity

I don't know how much of the complexity of writing multi-threaded code
can really be avoided.  Or maybe, how much benefit one has of multiple
cores when least complexity is the goal.

For me source code complexity of rewritten FR isn't the problem.
Finding the time to do it, and even more so staying motivated while
doing it certainly are the problems.

Anyway, just my 0.02 €.

Thanks

--
Michael Hieke


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flamerobin-devel mailing list
Flamerobin-devel@...
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel

[Milan Babuskov]

Michael Hieke wrote:
>> The main problem is: resources. If we continue at current pace, it
>> will be a long time before 2.0 reaches the feature set of current
>> 0.8.x code.
>
> That's true.  Development will most probably be even slower, because
> until now you simply implemented the features you needed for FR, while
> from here on that's not strictly necessary any more - FR 0.8 is already
> there to do the work...

Well, I do plan to add support for all new Firebird features, even if I
don't use them. For example, I don't use 2.1 at all, but I added support
for (probably all) new features.

It's just that you won't see some beginner-friendly features like 'Table
creation wizard' or similar coming from me ;)



--
Milan Babuskov
http://www.guacosoft.com


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flamerobin-devel mailing list
Flamerobin-devel@...
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel

[Michael Hieke]

On 21.07.2008 19:03 Milan Babuskov wrote:

>> That's true.  Development will most probably be even slower, because
>> until now you simply implemented the features you needed for FR, while
>> from here on that's not strictly necessary any more - FR 0.8 is already
>> there to do the work...
>
> Well, I do plan to add support for all new Firebird features, even if I
> don't use them. For example, I don't use 2.1 at all, but I added support
> for (probably all) new features.
>
> It's just that you won't see some beginner-friendly features like 'Table
> creation wizard' or similar coming from me ;)

Sorry, I wasn't clear enough.  I meant to say that development of a
version 2 of FlameRobin would be even slower than development of the
current code, as the need for a particular feature is probably already
cared for by current FR.  I remember that a lot of the features came
into being because you needed them for your work.

Thanks

--
Michael Hieke


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flamerobin-devel mailing list
Flamerobin-devel@...
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel

[Milan Babuskov-4]

On Mon, Jul 21, 2008 at 9:03 PM, Michael Hieke <mghie@...> wrote:
> Sorry, I wasn't clear enough.  I meant to say that development of a
> version 2 of FlameRobin would be even slower than development of the
> current code, as the need for a particular feature is probably already
> cared for by current FR.  I remember that a lot of the features came
> into being because you needed them for your work.

Yes, of course. FR2 would surely be a project with different goals (at
least for me).

Thank you for your comments,

--
Milan Babuskov
http://www.flamerobin.org

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flamerobin-devel mailing list
Flamerobin-devel@...
https://lists.sourceforge.net/lists/listinfo/flamerobin-devel