Re: [ST-devel] libst + gui = hosted event loop

[Wesley W. T. <we...@te...>]

On Wed, Apr 09, 2003 at 08:43:50PM -0700, fre...@ug... wrote:
> > On Tue, Mar 11, 2003 at 12:05:38PM -0800, fre...@ug... 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. :-)
> 
> I see... indeed, even linking with libpthread causes a segfault for
> me. Do you know what causes this?

Yes; pthread replaces some C library methods with new symbols.
These overloaded methods use a trick to find the thread context.
They get a bad context, try to read it, and boom!

I was looking into how to fix this, but got distracted.

The original problem: libst + gui could be solved by hosting glib on libst.
I have a source file which accomplishes this; it uses glib's ability to have
a replaced main event loop. This was enough for me since gtk does not use
libpthread. I just use st_poll to implement it.

However, gnome2 does, so anyone who wants to link to both gnome2 and libst
is ... screwed. That is why I was looking at it, but the pthread code has a
jungle of #ifdefs around the context locating code. I couldn't decide which
one it was actually using! At least one of the methods is to round the stack
up by a fixed stack size and take the base value as the context ptr. It is
clear why this + st wouldn't work.

Sorry I didn't post this half-positive result. At the time I was hoping for
a complete solution, but now I don't have an interest in fixing it.

---
Wes