libst + gui = hosted event loop

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