[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Potential spiped 1.6.1 release -- please test
On Sat, Dec 28, 2019 at 02:00:44PM +0200, Peter Pentchev wrote:
> It turns out that at least on Debian testing the pthread_cancel() function
> doesn't play very nice with threads that have already terminated - it
> returns ESRCH (no such thread/process).
New idea: what if the thread *hasn't started* yet?
In the "application usage" (informative section), the standard says:
There is no requirement on the implementation that the ID of the created
thread be available before the newly created thread starts executing.
So I'm imagining:
1. pushbits() runs pthread_create()
2. pushbits() finishes executing, and returns to main
3. test code calls pthread_cancel()
4. problem occurs
5. ... if no problem had occurred, *then* the new thread would start
executing and the thread ID would become valid.
I've sketched a solution in the
branch. It feels like overkill, but based on my interpretation of the
standard I think it's necessary .
 my original solution used semaphores and was much cleaner, but OSX doesn't
support unnamed semaphores (!!!). So I went with the clumsier approach of a
mutex, conditional variable, and int.