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

[Robert Watson]

On Sun, 19 Aug 2007, Robert Watson wrote:

> 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.

Just to follow up on this point: as with the other kse(2), thr(2), umtx(2), 
etc, interfaces, I think we should heavily discourage programmers from using 
them -- they are internal interfaces used to implement threading, and not 
general purpose application programming interfaces.  I think adding a 
libpthread-layer interface for killing threads in other processes would be a 
mistake for all the reasons that Daniel and others have pointed out.

Robert N M Watson
Computer Laboratory
University of Cambridge