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

[Bill Gunshannon]

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.

> 
> Of course ideally the OS should provide a very flexible threading
> system allow all languages/runtimes to encapsulate it in their
> API.
> 
> Arne
> 
> 

bill