Re: libst + gui = hosted event loop

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?

Frederik

"Wesley W. Terpstra" <[email protected]> writes:

> libst + gui ... right now impossible.
>
> We all agree that libst is great for servers. I think we probably all agree
> that libst is good for clients doing parallel requests (such as p2p apps).
>
> However, right now libst as a linkable library in the setting of an
> application with a gui is impossible.
>
> I want to run a proposed change by people here in the hopes that when I
> write it (I at least need this) it will be accepted into the main codebase.
>
> Here's my plan:
>
> Right now we have an ifdef POLL which at compile time selects our loop. I
> propose to always compile both version of this method with distinct names
> (if they are both available). The schedualer _st_vp_idle will simply
> delegate to a function pointer to one of these loops. The default value of
> the pointer will be whatever the ifndef POLL gave the user before.
>
> We add a new function st_set_loop(...) which selects what the user wants for
> the underlying loop. We then also expose st_select_loop and st_poll_loop.
>
> The interface:
> 	void st_select_loop(void* arg);
> 	void st_poll_loop(void* arg);
> 	void st_set_loop(void (*loop)(void* arg), void* arg);
>
> Now, for making libst work with GUI apps we can add a new (seperate) file
> for each loop we need to support. Simply expose a new loop method. The loop
> I intend to create (for myself) is one that plugs into glib.
>
> The part where I am become uncertain is how to keep libst dependentless.
>
> libst would be devalued if we linked to libglib -- it's big!
> Furthermore, if more event loops are added, libst requires more and more.
> This is unacceptable.
>
> However, if we compile the loops as seperate libraries, we run face-first
> into all the horrible inter-library dependency issues we really don't want
> to deal with.
>
> There are other options... all distasteful:
>
> Make each loop in a seperate header. You include <st-glib.h> in exactly the
> file with your main(), this dumps in the code into your source. (ick)
> (problem would then be: we need the private libst headers or some helper
> methods which manipulate the private datastructures)
>
> We include a pre-compiled object file for each loop if the compile-time
> dependencies are present (ick - needs configure bloat).
>
> A variant of the object file scheme, compile to independent libraries
> libst-glib, libst-kde, etc which simply replicate the required libst code
> rather than linking to a common libst library. (needs configure, but at
> least it is still only a library and has no crazy depends)
>
> ... anyways.
>
> What I want to know is if other would find this useful in mainstream libst.
> I also want to know what people think the best solution to keep libst small
> is (I personally lean towards the header solution, though it is evil).
>
> Finally, I want to know whether I should write this as part of libst (ie: it
> will get merged) or simply hack a hybrid libst directly into my application.
>
> I think the benefit of this also extends beyond simple gui-hosted event
> loops (which I admit will be a significant performance degredation), but
> also to allowing for easier integration of things like /dev/poll.
> Plus, sometimes a user of libst wants select() or poll() specifically based
> off of the number of file descriptors he expects to be working with.
>
> At any rate, the code is not the real issue. The real issue is how to
> integrate it in a low impact manner.
>
> -- 
> Wesley W. Terpstra <[email protected]>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> State-threads-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/state-threads-devel


-------------------------------------------------------
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