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