[Info-vax] Problems with multithreaded calls to libCURL

[Stephen Hoffman]

On 2019-03-07 23:09:33 +0000, Jim Duff said:

> If anyone has any ideas, or has implemented a multithreaded system 
> employing libCURL, I'd love to hear from you.

Maybe a libfetch port, under the "any ideas" part of that?
https://svnweb.freebsd.org/base/head/lib/libfetch/


As for reentrancy, mentioned else-thread: At least in older OpenVMS 
releases, "The routines getaddrinfo, getnameinfo, and freeaddrinfo, 
which are described as part of the Basic Socket Interface Extensions 
for IPv6 (RFC 2553bis), are not thread-safe."
Donno if that got fixed.  And per 1.9.1 in the older doc, there are 
different RTL modes around AST and thread reentrancy.  
decc$set_reentrancy() or /REENTRANT, etc.
ftp://ftp.hp.com/pub/openvms/doc/OVMS_731_CRTL_REF.PDF

Haven't looked at the libCURL port, but—if it's threaded—then it should 
also be compiled using /REENTRANT, or the OpenVMS code-path calling 
decc$set_reentrancy().

And if C sockets aren't selectively either AST or thread-reentrant, 
there's a decidedly large hole around security, as there's no 
$qio/$io_perform interface for any network security on OpenVMS.

Documentation in this area is clearly lacking.  But that omission seems 
to extend past the CRTL and the why-is-this-still-separate socket API, 
and into the RTLs and system services and the rest of the AST and KP 
discussions.  Be nice if there was a "thread-safe" and "AST-safe" 
attribute on the API declarations, but then VSI has more than a little 
documentation work pending.  And they've undoubtedly bigger 
documentation issues ahead of this.


-- 
Pure Personal Opinion | HoffmanLabs LLC