Re: libst + gui = hosted event loop

On Tue, Mar 11, 2003 at 12:05:38PM -0800, [email protected] wrote:
> Perhaps I'm missing some libst issue which would make this impossible,
> but if the GUI is not performance-critical, then why not have it run
> in one pthread, and have all the libst threads and the libst event
> loop (which might include some network client, etc.) in another
> pthread?

Well, for starters, libst + pthread = crash. :-)

Further, then you throw out all the nice almost-no-locking-required benefits
of using libst. I don't just mean for speed (you're right, it wouldn't be
performance critical), but I mean for stablity---no races, no deadlock.

Finally, what happens if two pthreads use IO functions?

In this case you could have a truly nasty bug where another pthread tries to
context switch into _st_vp_idle -- who knows what this would do. Bad things.

If you are going to have to put all the IO in exactly one pthread anyways,
and have to communicate with it somehow, one would probably be better off
simply making a slave process that the GUI talks to via a pipe.

However, I would rather have the option to keep the whole thing as one
simple process.

---
Wes


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en