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

[David Froble]

Bill Gunshannon wrote:
> On 7/27/2017 9:46 AM, David Froble wrote:
>> 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.
> 
> Funny you should say this. I used to say it all the time but
> the Ada fanatics still insisted that no matter how warped or
> incompatible it was between compilers multi-tasking should
> remain a part of the language as opposed to a part of the OS. :-)
> 
> bill
> 

Well, I guess that would depend on the multi-tasking being performed, and such. 
  Sure, an OS provides for multiple processes.  However, a single process may 
need to control and coordinate multiple "things".

I truly do not trust fanatics ....