[interfacekit] Re: One-thread-per-window

The main downside, IMHO, to per-window threading is that it's a bitch to
port toolkits which assume a per-application threading model (thinking
Qt and GTK here).  The upsides, in my mind, are huge, so this is really
something we should keep.  Not to mention, it would likely wreak havoc
with the kits -- they're designed from the ground up to be
multi-threaded.  Personally, I think a great deal of those complaints
are based in a poor understanding of multi-threaded programming.  Just
my opinion.

I *do* think, however, that a second mode should exist that is
per-application threaded -- specifically to support porting those other
toolkits.  I don't know if we should make it as explicit as a special
BApplication class; I was thinking more in terms of being able to
request that the app_server put windows in a given app in a single
thread -- it would be more of a special server-side window class.

Here's the part that gets tricky (thinking as I type here):  what if
some enterprising GTK hacker decides to put each of his windows in its
own thread?  I've never done any GTK programming, so this may not be an
easy (or even desireable) thing to do for that toolkit, but I think you
get the point.  I suppose we would simply deliver all messages to the
application thread and any communication between threads in the app is
up to the developer.

You know, this is something I think we should discuss with the entire
OpenBeOS group.  I'm going to throw mail out to the list -- I'm sure
there are folks there that have done Qt and GTK programming and can
comment more intelligently that I can.

e

DarkWyrm wrote:
> 
>     With all the feature talk on the OBOS list, I've been thinking, which
> some might consider dangerous. ;) One of the biggest complaints from
> developers that I've heard is the one-thread-per-window concept and forced
> multithreading.
>     How difficult would it be to provide an alternative to this but still
> keep the regular API at the same time? I mean like a couple extra classes in
> the Interface Kit which would utilize the same thread used by the
> BApplication class instead of starting their own, possibly being coupled with
> a special BApplication class. Then again, would this be a wise idea to do so?
> 
> --DW

Other related posts: