On Tue, May 14, 2002 at 11:21:23AM -0400, [EMAIL PROTECTED] wrote: > > Jarkko Hietaniemi wrote in reply to Craig Berry: > > !> http://www.openvms.compaq.com/commercial/c/5763p005.html#re_ent > ! > !It looks like the MULTITHREAD could be it. How that would require > !declaring the various _r and _r_proto macros (like d_localtime_r) > !in configure.com, I dunno. > > I _think_ that Craig was alluding to a possibility that adding > something like /REENTANCY=MULTITHREAD to ccflags might be a > way to go (I could be wrong). I'd like to point out section
Yes, I understood that. What *I* was alluding to is that if the MULTITHREAD reveals some _r prototypes in C headers, the corresponding macros in configure.com need to be tweaked, too, so that HAS_LOCALTIME_R et al get defined for reentr.h and reentr.c. > 1.9.2 of the cited URL document that states that mixing > AST (asynchronous system traps) type calls with MULTITHREADing > can be dangerous for a large number of C RTL calls including I/O. > Note that there are calls to sys$setast() in vms/vms.c and > they might need some disentangling to avoid the mutex deadlock > problem alluded to in: > > http://www.openvms.compaq.com/commercial/c/5763p005.html#multithread_restrict_sec > > Peter Prymmer > -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
