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

[Arne Vajhøj]

On 7/28/2017 8:08 PM, Bill Gunshannon wrote:
> On 7/28/2017 4:06 PM, Arne Vajhøj wrote:
>> On 7/28/2017 7:33 AM, Bill Gunshannon wrote:
>>> 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:
>>>>>>> "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.
>>
>>>>> 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. :-)
>>
>>>> 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".
>>
>>> 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.
>>
>> There is an argument for having the language or language runtime
>> provide the threading: it allows for the same model across all OS.
> 
> I think you missed the point.  The Ada standard does no such thing and
> leaves it up to the individual compiler implementer so that they can do
> completely incompatible multi-tasking implementations and still meet
> the standard.

I have never written any Ada tasking code.

But it is my understanding that Ada has a defined syntax with
at least somewhat defined semantics for tasking that should allow
an Ada program to behave functional equivalent on different
platforms.

Arne