At 7:09 AM -0600 3/21/06, Craig A. Berry wrote: >At 12:45 PM -0500 3/20/06, John E. Malmberg wrote: > >< discussion of kernel threads and upcalls snipped > > >>I looked at the code. Configure.com is setting up a special symbol that the >>procedure that converts descrip.mms_template to descrip.mms uses to change >>the linker behavior for it. This makes it harder to break apart the two >>flags. > >Yes, but perhaps we should figure out a way to do that since it seems >likely there will be contexts where one will get us out of trouble >and the other will get us into trouble.
I've just committed a patch that should take care of this. See http://public.activestate.com/cgi-bin/perlbrowse?patch=27593 for the implementation details. Here's the executive summary. For threaded builds, we now link the main Perl image with upcalls enabled by default on all architectures for VMS 7.1 and higher. You can disable upcalls by answering no to the upcall question during an interactive configuration, or you can pass -"Uusethreadupcalls" on the command line. For non-VAX systems at VMS 7.2 and higher, if you have enabled threads and upcalls, you can optionally also enable multiple kernel threads (which depend on upcalls). You can do this at configuration time by answering yes to the multiple kernel threads question or by passing -"Dusekernelthreads" on the command line. Note that this option will do you no good on a single-processor system or a system with the MULTITHREAD system parameter set to 1. I've left the default multiple kernel thread setting as disabled, at least for now. The upcalls change is a change in default behavior. It does get t/op/threads.t to pass (i.e., run without hanging). -- ____________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "Literary critics usually know what they're talking about. Even if they're wrong." -- Perl creator Larry Wall