Hello Markus. I think this is exactly what is going wrong. It fits the description of what i am seeing. The kernel man-pages even go so far as to state:
"The effects of this call in a multi-threaded process are unspecified." http://linux.die.net/man/2/signal So i guess using signal() inside wine is a no-go. I think this patch needs to be applied. I will try out the patch, and re-sync it if it has come out-of-date. Thanks, /pedro On Mon, 2008-10-20 at 09:44 +0200, Markus Amsler wrote: > Peter Dons Tychsen wrote: > > Hello. > > > > It starting with me trying to figure out why i was loosing keyboard > > events in winedos. > > > > 1) I then traced the keyboard events to a call to signal(SIGUSR2) in > > function DOSVM_QueueEvent(). > > > > 2) The signal() triggers code in ntdll, which generates an exception > > EXCEPTION_VM86_STI for the current vm86 context. > > > > 3) The exception is supposed to trigger exception_handler(), which will > > then handle the keyboard event, by kicking the event queue. > > > > This never happens however, as the mechanism stops working very quickly. > > > > I found out the code gets to raise_vm86_sti_exception in ntdll, and then > > stops. ntdll_get_thread_data()->vm86_ptr is NULL, so the STI exception > > is never signaled. > > > > Does anyone know more about the exception subsystem, and what could be > > causing this kind of strange behavior? > > > > I can mention that the system can generate EXCEPTION_VM86_INTx > > exceptions successfully, but fails to execute the EXCEPTION_VM86_STI. > > > > Thanks, > > > > /pedro > > > > One issue with dos input is (was?), that since 2.6 linux kernel we > should signal the thread not the process. Have a look at [1]. That patch > once fixed all my dos input issues, although I haven't looked at this > stuff for quite some time. > I'm not sure you have the same problem, just a possible hint. > > Markus > > [1] http://www.winehq.org/pipermail/wine-patches/2004-November/013645.html > >
