Re: Proposal: threads in glib.

[Aaron Digulla <digulla wi-pc44 fh-konstanz de>]

Quoting Sebastian Wilhelmi (wilhelmi@ira.uka.de):

> Even if I do not want to start another neverending thread (ah, what a
> delicious ambiguity;-), I'm afraid, I will. So here's my rational:
>
> 1. programming with threads is usefull.
>
> even if you have functions like .._add_idle in gtk, it still makes sense
> to program threaded applications (this holds true especially for gui
> applications).
>
> 2. most platforms have or will have threads.
>
> even though some platforms still do not provide support for threads, those
> platforms will eventually be replaced by ones, that do.
>
> 3. glib will live in non-posix environments
>
> glib is being ported to win32, where posix threads are not natively
> supported .
>
> All of that leads me to the conclusion, that glib needs a simple, but
> powerfull thread abstraction.

Here are my few cents: Thread support should be built into glib but
glib shouldn't try to implement a full thread API itself.

Currently glib doesn't work too well with threads (because the
idle/timeout problems: They aren't called under some circumstances).

IMHO, it would make more sense to make glib work with threads and
then maybe create a gthreadslib which contains this.

To make glib work with threads I need this:

- A way to check if events/idles/timeouts/etc. are pending
- A way to handle events/idles/timeouts/etc.

Currently, this happens all inside of gtk_mainloop() which I
can't influence. Just calling

    while (gtk_events_pending())
	gtk_main_iteration();

doesn't work. This will process events but idles/timeouts/etc.
won't work (which means that signals don't work anymore, for
example).

> I implemented such a beast in the spirit of glib, here's the README:
>
> ------8<-----------8<---------8<--------------------------
> This is a first shot for a cross platform thread library for glib.
>
> it is currently only implemented for posix threads, but should be
> portable to win32 and other platforms, that support threads.
>
> The whole thing is kind of similar to the NSPR API of netscapes cross
> platform library, but has a simpler interface, that should satisfy
> almost all needs. Also there are some functions, that are more nifty
> than in NSPR, especially the g_monitor_new_for_resource function,
> which is a much better version of the cached monitors in NSPR (it's
> faster and uses the same API as usual monitors).
>
> The whole thing is not very big (the stripped version of the lib is
> only about 4k on solaris).
>
> Here is the API:
>
> /* create a new thread and start it with the function thread_func,
>   which gets the argument arg. stack_size determines the stack for the
>   process, if zero the default stack size is taken. */
> GThread* g_thread_new(GThreadFunc thread_func,
>		      gpointer arg,
>		      guint stack_size);
>
> /* the calling thread is blocked until thread is completed, returns
>    FALSE, if thread is invalid. */
> gboolean g_thread_join(GThread* thread);
>
> /* get a reference to the current thread */
> GThread* g_thread_get_current();
>
> /* allocate a new slot for private data. it is associated with the
>    returned id. all non-zero data registered by a thread will be
>    handed over to destroy_func, whenever the data is set again or
>    when the threads ends. */
> GThreadPrivate* g_thread_private_new(GDestroyNotify destroy_func);

Why is this called _private_ instead of _data_ ?

> /* create a new monitor. */
> GMonitor* g_monitor_new();
>
> /* get the monitor, that is related to resource. That way you don't
>    have to create a mutex centrally, but simply use it on an agreed
>    pointer, i.e. a address of an object */
> GMonitor* g_monitor_new_for_resource(gpointer resource);

Hmm... does this mean that every resource can only have a single
monitor ?

> It is still questionable, whether there should be more options to the
> thread_new and monitor_new functions. But the more options, the more
> problems for porting and the benefits are not always obviuos (but might
> exist).

Well, half of the API is missing: You need ways to protect shared data
(semaphores) and ways to exchange shared data (message lists, etc). :-)

--
Dipl. Inf. (FH) Aaron "Optimizer" Digulla     Assistent im BIKS Labor, FB WI
"(to) optimize: Make a program faster by      FH Konstanz, Brauneggerstr. 55
improving the algorithms rather than by       Tel:+49-7531-206-514
buying a faster machine."                     EMail: digulla@fh-konstanz.de