The problem is that by the time that Wine has been initialized,using setjmp/longjmp will always lead to a crash. The code in pthreads that performs the longjmp will first try to invoke the pthread cleanup routines, and then invoke longjmp. This never happens.
You can't and needn't link with -lpthread. Wine has its own pthread implmentation.
I tried your included code and it works just fine unless you link with -lpthread, then it crashes in the same way as in your attached picture. But then you should never link Wine with -lpthread so that is not really a bug.
Of course Wine pthread implementation it not in any way complete so some function might be missing and some might only be only partially implemented and of course some might be incorrectly implemented.
So please try again without linking with -lpthread.
Hello,
The problem is that by the time that Wine has been initialized,using setjmp/longjmp will always lead to a crash. The code in pthreads that performs the longjmp will first try to invoke the pthread cleanup routines, and then invoke longjmp. This never happens.
You can't and needn't link with -lpthread. Wine has its own pthread implmentation.
I tried your included code and it works just fine unless you link with -lpthread, then it crashes in the same way as in your attached picture. But then you should never link Wine with -lpthread so that is not really a bug.
Of course Wine pthread implementation it not in any way complete so some function might be missing and some might only be only partially implemented and of course some might be incorrectly implemented.
So please try again without linking with -lpthread.
The problem is that this is very hard for us to do as two of the underlying libraries we are using (libmono and libgc) both link against pthread to achieve their threading capabilities.
It might be better to investigate what are Wine's requirements for having its own pthread implementation, and have those changed pushed to the maintainers of pthreads.
In particular, we are interested in using WineLib, maybe it would be possible to have WineLib use the standard pthread implementation instead of rolling its own?
Miguel.
On Wed, Dec 11, 2002 at 01:05:32PM -0500, Miguel de Icaza wrote:
Hello,
The problem is that by the time that Wine has been initialized,using setjmp/longjmp will always lead to a crash. The code in pthreads that performs the longjmp will first try to invoke the pthread cleanup routines, and then invoke longjmp. This never happens.
You can't and needn't link with -lpthread. Wine has its own pthread implmentation.
I tried your included code and it works just fine unless you link with -lpthread, then it crashes in the same way as in your attached picture. But then you should never link Wine with -lpthread so that is not really a bug.
Of course Wine pthread implementation it not in any way complete so some function might be missing and some might only be only partially implemented and of course some might be incorrectly implemented.
So please try again without linking with -lpthread.
The problem is that this is very hard for us to do as two of the underlying libraries we are using (libmono and libgc) both link against pthread to achieve their threading capabilities.
It might be better to investigate what are Wine's requirements for having its own pthread implementation, and have those changed pushed to the maintainers of pthreads.
In particular, we are interested in using WineLib, maybe it would be possible to have WineLib use the standard pthread implementation instead of rolling its own?
This would be very difficult.
WINE implements the Win32 threading/process and synchronisation model. It needs to use the OS native threads so it gets the stack maintenance and the correct handling of the %fs.
So WINE cannot change to pthreads without major hacks to the pthread library I guess.
Ciao, Marcus
-
Marcus Meissner -
Miguel de Icaza -
Patrik Stridvall