Re: libst + gui = hosted event loop

Jose Marcio Martins da Cruz <[email protected]> Thu, 10 Apr 2003 13:19:13 +0200
Newsgroups gmane.comp.lib.state-threads.devel
Organization Ecole des Mines de Paris
Message-ID <[email protected]>

Hi,


The first time I read about state threads, what I found very interesting, and
surely to many people, is the probable high performance at some internet
servers, which surely doesn't have any type of graphical interface : web
servers, smtp servers, proxies, ...

I'm afraid of including graphical libraries such as glib, and lack the interest
of state threads library to high performance servers.

But maybe I'm wrong.

My two cents.

Jose Marcio


"Wesley W. Terpstra" wrote:
> 
> On Wed, Apr 09, 2003 at 08:43:50PM -0700, [email protected] wrote:
> > > 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. :-)
> >
> > 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
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> State-threads-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/state-threads-devel

-- 
 ---------------------------------------------------------------
 Jose Marcio MARTINS DA CRUZ           Tel. :(33) 01.40.51.93.41
 Ecole Nationale Superieure des Mines de Paris   
 Centre de Calcul                      http://j-chkmail.ensmp.fr
 60, bd Saint Michel                http://www.ensmp.fr/~martins
 75272 - PARIS CEDEX 06      mailto:[email protected]        
 ---------------------------------------------------------------


-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
for complex code. Debugging C/C++ programs can leave you feeling lost and 
disoriented. TotalView can help you find your way. Available on major UNIX 
and Linux platforms. Try it free. www.etnus.com