But my patch fixes the problem. In researching the problem I found a pthreads tutorial that said if you are using pthread_cond_wait() outside the body of an if statement, you are probably not using it properly. So my patch adds a boolean named IsSet to the intRTLEvent record. It is only set, reset, or tested inside the mutex lock/unlock blocks. RTLEventSetEvent sets the boolean. RTLEventWaitFor calls pthread_cond_wait() if IsSet is false. After that RTLEventWaitFor clears the IsSet boolean.
The result is if one thread calls RTLEventSetEvent() and later another calls RTLEventStartWait the second threads call to RTLEventWaitFor will not wait. But if the order is reversed, the calls work like they did in the past. On 12/15/06, Micha Nelissen <[EMAIL PROTECTED]> wrote:
Lloyd Park wrote: > I had problems with a threaded app under Linux which hung because one > thread would sometimes call RTLSetEvent before the other called > RTLEventStartWait. The attached patch for the 2.1.1 branch revision > 5606 fixes the problem. Better rewrite it to use semaphore (sem_*) functions. The conditional variables are very disappointing (exactly for the reason you describe). Micha _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
