Re: Potential spiped 1.6.1 release -- please test

[Graham Percival <gperciva@tarsnap.com>]

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. 
    https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_create.html

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
https://github.com/Tarsnap/spiped/tree/pushbits-wait-for-start
branch.  It feels like overkill, but based on my interpretation of the
standard I think it's necessary [1].

[1] 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.

Cheers,
- Graham