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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
