[Info-vax] pthread_kill() replacement for VMS?

[David Froble]

John Reagan wrote:
> On Thursday, July 27, 2017 at 8:59:52 AM UTC-4, John E. Malmberg wrote:
>> Hello all,
>>
>> One of the gnulib tests is doing a pthread_kill call which does not 
>> exist on VMS.
>>
>> Is there a quick fix to create such a routine?
>>
>> Regards,
>> -John
> 
> Ah, pthread_kill.  The "standard" way to write non-portable code.
> 
> It is mixing both threads and signals together.  Signals are an emulation of the CRTL, not really part of the OS.  In some cases, you can turn the pthread_kill into pthread_cancel/pthread_testcancel.
> 
> Here's the stock answer from the threads notefile when pthread_kill has been asked for over the years (in particular, from others who ported the gnulib going as far back as the early 2000s)
> 
> "The foremost is that UNIX signals are emulated on OpenVMS, and that emulation
> is provided by the C RTL, not by the base OS.  Thus, the C RTL would be the
> logical host for pthead_kill(), not the threads library.  However, the C RTL,
> by design, cannot contain any static references to the threads library, nor
> does it have any ability to effect signal delivery in a thread other than the
> current one, and so considerable support would have to be provided by the
> threads library for the C RTL.  (All of this is ignoring the fact that the
> signal handler vector and signal delivery masks are currently global and not
> per-thread.)"

Another example of software anarchy in place of well thought out software 
architecture.

Just like the attempt to implement byte range locking in the CRTL, instead of 
the logical place, the DLM that exists to provide locking.

Yes, in the end, it's all ones and zeros, and just a long string of instructions 
being executed.  But, when something is fundamentally an OS feature, that's 
where is should be, not fudged in elsewhere.