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

[Bill Gunshannon]

On 7/27/2017 8:18 PM, David Froble wrote:
> 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 ....

While that may be true, according to the standard Ada multi-tasking
is downright hilarious.  On one implementation it can be synchronous
while on another it can be asynchronous and both will meet the
standard.

Unless you are running an OS that does not support tasking at all,
it should remain in the OS.  Having multiple controllers trying to
do the tasking is sure to result in conflicts including race
conditions, deadlocks and god only knows what else.  A single
process can control and coordinate multiple "things" even if the
actual multi-tasking is done by the OS. That's what IPC is for.

bill