Re: GNU-Pth and GLIB

[otaylor redhat com]

Jonas Bulow <jonas bulow servicefactory se> writes:

> otaylor redhat com wrote:
> > 
> > Jonas Bulow <jonas bulow servicefactory se> writes:
> > 
> > > Hi,
> > >
> > > Would it be of interest to have native GNU-Pth as a thread
> > > implementation besides POSIX and Solaris?
> > >
> > > Has anyone done any work on this?
> > 
> > A patch would probably be accepted - though I think GNU-Pth is
> > basically uninteresting. User space threads are just not ever going to
> > be as good as native threads, and basically all interesting platforms
> > now have native threads.
> 
> In an event driven server application it can be usefull to have a
> non-preemtive thread implementation. I found it easier to keep data
> consistent because no locking of data is needed. Of course there are a
> few assumptions that have to be true, for example processing time for an
> event should be minimized between calls to a yielding function.

Well, perhaps, though I'd be worried about accidentally forgetting
to make sure that I was reentrant over a call to, say, read() which
yielded when I wasn't expecting it to.

As I said, I think we'd be willing to take patches. 

You should also be able to use your thread library of choice by
passing the appropriate vector to g_thread_init(). 

The library that is compiled into gthread is really supposed to be
good enough to use interchangeably with a native thread
implementation, and I'm not quite sure that a user-space
implementation would meet that criteria.

Also, I'd really consider it broken to compile GLib, on say, Linux
with something other than native thread support, because there is the
expectation that you can mix use of GLib's thread support with
direct calls to system threading functions. So, some applications
might not function correctly.

Regards,
                                        Owen