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

[Robert Watson]

On Sun, 19 Aug 2007, Scott Long wrote:

> Robert's comparison to Linux is only half-valid.  There's really no reason 
> to hold linux's clone/vfork threads up as a model to emulate via a new 
> first-class interface into the kernel.  If you want to emulate it, compile 
> your app against the linux-threads package and be done with it.
>
> The Linux developers are moving beyond that primitive "threads" package 
> anyways and onto real threads and a complementary API to manage those 
> threads.  So tkill and tgkill are interesting things to look at, not just 
> here but in the broader need to work with Linux both at a source and a 
> binary level.  I believe that Dan also suggested something along this line 
> in his discussion about having Solaris-style (and thus linux-style) thread 
> groups, so I'm not exactly sure who is disagreeing with whom in Robert's 
> response.  Thread groups do seem like a logical next step, but it's 
> impossible to say at this point whether the syscall API to support them 
> would at all be served by the syscall that was just added.  If it isn't, 
> then this syscall becomes a 1-off orphan and a long-term liability to both 
> users and developers.  That's what ultimately needs to be avoided.
>
> So, supporting Wine is definitely a good idea, and there's no doubt a good 
> solution available.  It just makes me nervous when syscalls are added with 
> such little discussion and commitment.

I think the misunderstanding here is in thinking that Wine is an application 
that can program to the pthreads API and behave in a normal way.  Instead, 
think of it as including its own threads library implementing Windows 
threading behavior.  On the whole, the existing thread calls meet the needs of 
Wine, and often it can access them via pthreads, but there are times when it 
needs to *know* how threading works, and in those cases, accessing threads via 
low-level system call like thr_kill2(2) or via ptrace(2) may be entirely 
appropriate.

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) 
isn't a good match.  We have a plethora of low level threads system calls that 
applications generally shouldn't touch -- rfork(2), kse_*(2), thr_*(2), 
umtx_*(2), etc.  Last time I checked, Valgrind on FreeBSD did something very 
similar, relying on low-level umtx(2) system calls.

Robert N M Watson
Computer Laboratory
University of Cambridge