On Wed, 2006-12-13 at 17:42 +0000, Paul Brook wrote: > Qemu doesn't currently have any real thread support. It has a few hacks that > work for simple linuxthreads cases, but I doubt real multithreaded > applications will work. > > My point was that instead of blindly passing the threading syscalls through > to > the host we should consider using the host libc/libpthread thread support.
Well, let's break things down individually. - sys_set_thread_area(): - sys_get_thread_area(): - clone(CLONE_SETTLS) This _is_ handled in qemu, since it's just a case of loading new stuff into the emulated GDT. (Well, I didn't do get_thread_area but it's simple). - sys_futex(): We have to translate these into calls to the host's sys_futex() anyway. I need to go through the rest of the futex operations and see how many we can emulate cross-endian, and perhaps add some kernel support to make the answer "all of them". - sys_set_tid_address(): - clone(CLONE_CHILD_CLEARTID): We _could_ manage to do this in qemu for controlled thread exit -- it would be hard for uncontrolled exit though. But I don't see any harm in just letting the kernel do it either. I don't mind too much, but if we can let the kernel do it I'm happier that way. - clone(CLONE_PARENT_SETTID): - clone(CLONE_CHILD_SETTID): We need endianness-mangling on these so we have to get involved somehow. But I think we do need to use the kernel's support and then marshal the result back to the guest's memory. -- dwmw2 _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
