pthread_kill() replacement for VMS?

[John E. Malmberg]

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

[John Reagan]

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.)"

[David Froble]

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.

[Scott Dorsey]

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.

Good.

> Is there a quick fix to create such a routine?

No. Any time you see code using such a thing, it is inherently unsafe.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[johnwa...@yahoo.co.uk]

Eric W Robertson (?) made similar inquiries in comp.os.vms
(wrt gnulib) in 2013. Don't know if they led anywwhere in
private but they didn't go far in comp.os.vms.

Here's a snippet:

"I was looking to take a gander at some of the core pthread
API functions to see how difficult implementing the pthread_kill()
and pthread_sigmask() routines would be for OpenVMS. For some
reason these functions are only implemented for Tru64 and not
for OpenVMS. These thread functions are referenced by a couple
of Open Source Projects. I was attempting to survey the work
required to implement these functions (missing on OpenVMS) to
supplement the existing OpenVMS pthread RTL as I a believe
that these functions should not be terrifically difficult to
implement."

Best of luck.

[Bill Gunshannon]

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

[Stephen Hoffman]

On 2017-07-27 13:20:50 +0000, John Reagan said:

> Ah, pthread_kill. The "standard" way to write non-portable code.

Also known as a case where OpenVMS diverges from defacto implementation
standards.

> It is mixing both threads and signals together. Signals are an
> emulation of the CRTL, not really part of the OS.

That's been slowly and incrementally changing, though. q.v. the
sys$ssio* calls, and the sys$sigprc call, probably among others.

I see that $sigprc isn't in STARLET.SDL, but is still in
SYS$PUBLIC_VECTORS.EXE. But I digress.

> 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.

Ayup. But then I'm also on record supporting the retirement of the
current C RTL design and implementation (including CMA/pthreads, and
the separate sockets giblets. Of replacing it with a new C RTL, and
preferably one with additions such as a ubiquitous and system-wide
preferences-file implementation, and with integration into the image
activator to avoid those blasted DECC$ logical names, and related. Of
the addition of both SSIO and the most common missing C calls, too.
With VSIC$ or some such. Basically, of replacing the current design
with one that better matches C11 and POSIX and with better BSD and
Linux compatibility.



--
Pure Personal Opinion | HoffmanLabs LLC

[Stephen Hoffman]

On 2017-07-27 14:04:30 +0000, Scott Dorsey said:

> On Thursday, July 27, 2017 at 8:59:52 AM UTC-4, John E. Malmberg wrote:
>>
>> One of the gnulib tests is doing a pthread_kill call which does not
>> exist on VMS.
>
> Good.
>
>> Is there a quick fix to create such a routine?
>
> No. Any time you see code using such a thing, it is inherently unsafe.

The pthread_kill call is part of the POSIX.1 IEEE Std 1003.1-2008 standard:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html

[Scott Dorsey]

It certainly is, but that doesn't make it a good idea.

[Stephen Hoffman]

have So two problems now they?

There's been some debate about implementing threads correctly, and also
implementing threads as a library, too.

http://www.hpl.hp.com/techreports/2009/HPL-2009-259.html
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html

C11 and C++11 are rather better here...

https://stackoverflow.com/questions/8876043/multi-threading-support-in-c11#8877562

http://www.hboehm.info/c++mm/

I personally find that libdispatch/GCD and blocks and the C11 bits are
preferable to the POSIX threading approach, or KP Threads if I'm
strictly using OpenVMS, but then there are apps and folks that can and
will need the POSIX threading giblets, and other POSIX-related C calls.
Including the pthread_kill call.

In terms of implementations, OpenVMS doc has had some documentation
gaps around properly mixing threads and ASTs in user code. And
OpenVMS needs better POSIX and gcc/clang-compatible support in general.

[David Froble]

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 ....

[Bill Gunshannon]

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

[Stephen Hoffman]

On 2017-07-28 00:18:07 +0000, David Froble said:

> 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".

Distributed job schedulers have made that effort easier, and with less
bespoke code necessary. DLM and termination mailboxes and TCP and the
queue manager are all good tools and can be useful here, but adapting
those pieces and frameworks to scheduling is a fair amount of bespoke
code. But processes and process scheduling and distributed schedulers
are different from threading, and threading is something that really
doesn't exist in BASIC short of KP Threads or such. I've yet to
encounter threaded BASIC code. Lots of AST-based code and
multiple-process code written in BASIC certainly, but not threading.

> I truly do not trust fanatics ....

Ayup; those unthinkingly for or against any platform.

[John Reagan]

On Friday, July 28, 2017 at 10:58:53 AM UTC-4, Stephen Hoffman wrote:
> On 2017-07-28 00:18:07 +0000, David Froble said:
>
> > 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".
>
> Distributed job schedulers have made that effort easier, and with less
> bespoke code necessary. DLM and termination mailboxes and TCP and the
> queue manager are all good tools and can be useful here, but adapting
> those pieces and frameworks to scheduling is a fair amount of bespoke
> code. But processes and process scheduling and distributed schedulers
> are different from threading, and threading is something that really
> doesn't exist in BASIC short of KP Threads or such. I've yet to
> encounter threaded BASIC code. Lots of AST-based code and
> multiple-process code written in BASIC certainly, but not threading.
>

The BASIC RTL is not thread-safe. There is something in the BASIC release notes about it. I don't think the COBOL RTL is thread safe either. I don't about Fortran. I know the Pascal RTL IS thread safe since I did that work and I know a few Pascal customers that use threading with Pascal.

[David Froble]

No, VAX/DEC Basic doesn't support threads.

Since I've spent time there, I won't know nearly as much about using threads as
some might. With one exception, and my ignorance, I think there may have been
only one time when the use of threads would have been helpful. Mainly, I don't
miss the capability.

But since you've posted here John, can I ask, what type of effort is involved in
implementing threads in a compiler / language? Or, would it be easier to start
over. Would allowing threads then disqualify some other things the language
supports?

Could VAX/DEC Basic be modified to support threads, if you've looked at it
enough to take a guess?

Not looking for anything, just curious.

[John Reagan]

The compiler doesn't particular care but then we don't support any of the TLS that can use on Linux boxes. I'm lobbying hard for TLS support for x86 especially since clang/LLVM understand it.

For the RTLs, there is just lots of static data that assumes that it can be manipulated just by disabling ASTs for a period of time. That isn't enough for pthreads() and the like if you enable upcalls and multiple kernel threads. Those are off by default today, but I'm also lobbying for them to be turned on and stay on - a 'mandatory default' to coin a phrase :)

For the Pascal RTL, there is a single data structure to track open files. If multiple threads are opening/closing files, that linked list needs to be guarded. You can use locks or some atomic flag or TLS services etc. For the BASIC RTL, we looked several years ago and it is chocked full of static data structures that would need to be turned some per-thread or at least have some atomic access implemented.

[Arne Vajhøj]

I have a theory that languages with a strong tradition for
recursive calls are easier to make thread safe.

Arne

[Arne Vajhøj]

>>> 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

[Bill Gunshannon]

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

[Arne Vajhøj]

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

[Bob Koehler]

In article <c5955b28-66aa-4ca3...@googlegroups.com>, John Reagan <xyzz...@gmail.com> writes:
>
> The BASIC RTL is not thread-safe. There is something in the BASIC release =
> notes about it. I don't think the COBOL RTL is thread safe either. I don'=
> t about Fortran. I know the Pascal RTL IS thread safe since I did that wor=

> k and I know a few Pascal customers that use threading with Pascal.

I don't know about the whole RTL, but Fortran I/O was not thread safe
last time I messed with it and I haven't seen anything that would
suggest otherwize.

[Johnny Billquist]

Which means Ada do not have to implement multi-tasking on its own at
all, but can use the OS primitives to do it. So the conflict you paint
up is by no means mandatory just because you use Ada. All Ada does is
that it gives you the tools to handle this in a consistent and
predictable way from within the language. How it actually is implemented
is up to the implementor.

There is no such thing as "remain in the OS" as if it was an isolated,
separate thing. Sometimes you want to handle multiple tasks from your
code, and that means you either need some external library to do it, or
some built-in capabilities in the language. Just is just two different
ways to access and control this. That has nothing to do where the actual
multi-tasking as such is implemented.

IPC is just a buzzword here. In reality it means either having some
capability in the language to access it, or some external library with
functions to call. Nothing different.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol