On Fri, Feb 20, 2004 at 10:01:34AM +1030, Brett Lymn wrote:
> On Thu, Feb 19, 2004 at 02:55:01PM -0500, Jan Harkes wrote:
> > In any case, this is the non-trivial part of LWP. There are several
> > 'recently introduced' portable C functions such as setjmp/longjmp and
> > even better setcontext/getcontext. Ideally LWP would use those in
> > preference to the assembly routines, except that getcontext and longjmp
> > really don't match the semantics of returnto. At a first try, I
> > couldn't (easily) implement either one given the other.
> 
> Would it not be better to use another recently introduced library
> called pthreads? ;)  The arla people have a pthread'ified version of
> lwp which would mean that lwp would be immediately portable to all
> platforms that support libpthread without having to hack assembly
> language.... having done that for NetBSD/amd64 I can tell you that
> would be a real bonus.

Actually, we have lwp_pt, which is already in the lwp source tree. It
provides an LWP compatible wrapper around pthreads. It is just that not
all platforms support(ed?) pthreads (cygwin in particular) when it was
written, and all code using it needs to be compiled with a -D_REENTRANT
flag. This makes this version not easily drop-in compatible.

(oh, and using pthreads causes a pretty significant slowdown. LWP is at
least 10x faster when doing simple thread switches and even more when
grabbing something like an uncontested lock simply because we don't have
to synchronize with other threads)

But I did use it successfully to debug a memory problem in venus with
valgrind, as valgrind really doesn't like LWP at all ;).

Jan