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

Reply via email to