[Info-vax] Listeners in VMS Basic, was: Re: Integrity iLO Configuration?

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Sat Jun 26 20:20:39 EDT 2021


On 2021-06-26 18:49:53 +0000, Arne Vajhj said:

> On 6/25/2021 9:24 PM, Stephen Hoffman wrote:
>> On 2021-06-25 23:26:19 +0000, Arne Vajhj said:
>> 
>>> Why not pthreads?
>> 
>> pthreads is not my preferred threading model nor my preferred threading 
>> API. Not after using some of the other threading implementations 
>> around. Nor is the pthreads API friendly to BASIC code.
>> 
>> Specifically for established and existing OpenVMS apps, KP Threads is a 
>> more familiar interface such as when working in BASIC.
> 
> There is at least one advantage with pthreads - it is a standard. It is 
> actually possible to get help with it, because it is widely used.

pthreads is not my preferred threading.

pthreads is not something I'd prefer to interface with BASIC, either.

As for threading-based designs more generally, I'm skeptical that the 
added complexity of adding threading into an established OpenVMS app 
provides any particular advantage here over a pool of server processes.

And I'd prefer to performance-profile the whole existing environment 
under load, looking for where the time is going.

And whether—for instance—reconfiguring the app design for sharding or 
other approaches, or communications to message-passing design, or other 
changes, might work well enough and within the existing app design?

> And I can only halfway follow your problem with the model.

Other than the "I don't prefer the pthreads model", and "add-on 
threading libraries don't work well for threading without language 
help", you mean?

C and volatile has long been an adventure, too. That's all getting 
better, but still problematic in places.  Here's an older intro to the 
"fun" with C volatile:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html

BASIC last I checked had no analogous storage-access support for what C 
refers to as volatile storage, such multiprocessing-related 
synchronization was based on interlocked bitlocks and ilk. Which was 
discussed here back in 2019.
https://groups.google.com/g/comp.os.vms/c/Zf9tM2UkKAE/m/awJ6Tp-yAQAJ

> The pthreads model is the basic model used by almost all threading 
> systems as the lowest level thread API.

pthreads might be the lowest-level on some platforms, though not on the 
platforms I'm dealing with, including not on OpenVMS. KP Threads is the 
lowest level threading API on OpenVMS, for those not creating their own.

> Java, .NET, Windows, Boost/C++ 11, Qt, Delphi etc. all provide a similar API.

None of which I'd choose to use on OpenVMS, where (when) those tools 
(Java) are even available for OpenVMS.

And if I were to consider the use of some of those tools—opening up a 
much wider discussion during these sorts of app refactoring and app 
retrofitting—I'd also necessarily be obligated to consider porting some 
or all of the app to some other platform, either front-end or more.

> But the foundation is still the basic thread API.

Alas, pthreads is not the foundation of threading on OpenVMS.

>> And if I wanted to overhaul or to re-write the existing BASIC app to 
>> use pthreads, or Java or Python or PHP, or other such efforts, I'd 
>> seriously consider re-hosting the entire app else-platform as that's 
>> headed for a re-write.
> 
> Migrating the VMS Basic code to another platform is likely impossible 
> short/mid term.

Grafting a threading design into an established BASIC app environment 
is no small effort, either.

Adding ASTs alone into an existing app can become a design, 
implementation, and refactoring adventure, for those apps not currently 
using ASTs.

And handing off an SSL/TLS connection is not something I'd prefer to 
tangle with within a project, nor would be having a zillion TLS 
connections into one multi-threaded server process.

But again, I'd profile the whole environment, and with a discussion for 
where the app developer wants to end up after the work both short-term 
and longer-term.

Haven't looked at porting VSI BASIC to the various BASIC compilers for 
Unix in a while, nor at porting to the VBS/VBN stuff, nor Sector7 
support. That's almost certainly out-of-scope here, at least short 
term. But there are BASIC compilers around.



-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list