Re: next round: glib thread safety proposal

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

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

> I define the following struct in glib.h
>
> typedef struct _GMutexFunctions GMutexFunctions;
> struct _GMutexFunctions
> {
>   gpointer (*mutex_new)       ();
>   void     (*mutex_lock)      (gpointer mutex);
>   gboolean (*mutex_trylock)   (gpointer mutex);
>   void     (*mutex_unlock)    (gpointer mutex);
>   void     (*mutex_free)      (gpointer mutex);
>   gpointer (*cond_new)        ();
>   void     (*cond_signal)     (gpointer cond);
>   void     (*cond_broadcast)  (gpointer cond);
>   void     (*cond_wait)       (gpointer cond, gpointer mutex);
>   gboolean (*cond_timed_wait) (gpointer cond, gpointer mutex, gulong
> duration);
>   void     (*cond_free)       (gpointer cond);
> };

Just a sidenote: I see that mutexes and conditions are closely related
but I still don't like two functions in one structure. Just image we
wanted to add one more function to mutexes: Some old code might call
it for cond_new :-/ I don't know if that's a real problem but you
shouldn't merge the two.

Which brings me to the next point: Why don't you use the OO system
which is used for the Gtk widgets here ? Something like

struct _GObject
{
   gpointer (*obj_new)       ();
   void     (*obj_free)      (gpointer obj);
};

could be used as the basis of all kinds of objects which can be
allocated and freed. That would make the API again a bit more
"orthogonal".

>[...]
> So do something like:
>
> G_MUTEX_STANDARD_IMPLEMENTATION;
>
> int
> main()
> {
>   /* working thread safe on platforms with and without weak symbols */
> }
>
> Such a prog of course has to be linked with the apropriate thread library,
> whereas other programs using glib needn't. I have not written that down so
> far, but if there will be some consensus on the proposed thechnique, I'll
> do a nice framework. (including configure.in stuff). We might also define
> some opaque types GMutex, GCondition and use GMutex* and GCondition* resp.
> instead of gpointer to make the whole thing look more like glib. Also
> inline code on compilers that does support them will be better than
> defines, it generally makes error messages much simpler to parse for
> humans.

I'd like this: If possible, the same version of GLIB should work with
and without threads (ie. even without linking against at thread lib).

If I need threads, I would add --with-threads to the call to glib-config
which would then add the necessary flags/libs.

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