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

[Arne Vajhøj]

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.

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

Arne