Re: next round: glib thread safety proposal

[Owen Taylor <otaylor redhat com>]

Sebastian Wilhelmi <wilhelmi@ira.uka.de> writes:

> Hi, Owen
> 
> > > I thought, that we should switch our internal locking mechanism, if so
> > > desired by g_thread_init()? If not, we can of course stick to the 
> > > default
> > > implementaion with the fallback, as already provided. My solution will
> > > however use the provided mutexes. I do not know any situation, where the
> > > default mutexes arn't good enough to achive glib thread safetey, so I
> > > would really welcome to just leave out the 'runtime_mutex'
> > 
> > No, I don't want to do that. We can't assume we'll have default
> > mutexes at all on a platform that wants to use the user provided
> > thread funcs.
> 
> So, did I get it right: We will use the default implementation for
> GStaticMutex, no matter what the user supplies in g_thread_init(), but
> provide a fallback for systems without a default implementation, that
> implements GStaticMutex by means of GMutex, as supplied with
> g_thread_init()?

I guess my feeling is, that if the user supplies thread funcs,
we _have_ to use them. If, say, the default mutexes are from
a kernel threading package, and the supplied mutex from
a a user space thread package - if a kernel mutex can't be
claimed, instead of scheduling another user thread, it will
either try to schedule another kernel thread, or possible
error out because it detects a mutex recursion.

Regards,
                                        Owen