cvs commit: src/sys/kern kern_thr.c syscalls.master src/sys/sys

[Poul-Henning Kamp]

In message <20070819185019.M81759 at fledge.watson.org>, Robert Watson writes:

>Tijl's example of having aligned thread IDs for use between ptrace(2) and the 
>thr_*(2) system calls is a particularly good example of a case where the clean 
>pthreads abstraction (which has no notion of how to interact with debuggers) 

Calling "pthreads clean" is an act of spin that I find actionable.

"Spartan", "rudimentary" or most precisely: "primitive" all describe
pthreads much better than "clean".

I say this as an old ass-hole who have done multiprogramming in various
environments since 1980 and as somebody who has never been able to fathom
how pthreads came to be without even basic development and debugging aids
such as, for instance, a pthread_mutex_assert_held() function.

I also fully agree that Wine isn't an application, it is an emulation
framework for a alien API, and thus any argument based on pthreads,
so called, purity is bollocks.

If Wine needs this to work and we need Wine to work, then we need this.

Remember: "FreeBSD: Tools, not politics"

>Last time I checked, Valgrind on FreeBSD did something very 
>similar, relying on low-level umtx(2) system calls.

Actually I'm helping peter on valgrind and I got it to handle a new
thread started with thr_new() only yesterday.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.