Fix identified for OpenVMS threaded Perl hangs.

FAQ

Memberlist

Usergroups

Profile

Preferences

· nixdoc.net

· man pages

· Linux HOWTOs

· FreeBSD Tips

· Forums

Forum index » Not Unix » VMS » vmsperl

Fix identified for OpenVMS threaded Perl hangs.

Page 1 of 1 [11 Posts]

View previous topic :: View next topic

Author

Message

John E. Malmberg
*nix forums Guru Wannabe

Joined: 30 May 2005
Posts: 264

Posted: Thu Mar 16, 2006 12:02 pm Post subject: Note

Fix identified for OpenVMS threaded Perl hangs.

I have found that the link command for executables needs to be changed
for threaded Perl build. The additional qualifiers are ignored for
shared images.

I am not sure how to modify configure.com and descrip.mms_template etc
to do this.

When building a threaded Perl, the link command should be:

$LINK :== LINK/THREADS_ENABLE=(MULTIPLE,UPCALLS)

Setting the above command before building Perl is the current work
around that I am using.

The UPCALLS is needed to prevent calls to sleep(), SYS$HIBER(),
usleep(), nanosleep(), and several other timed waits from becoming
permanent.

The MULTIPLE allows the threaded Perl to take advantage of
multi-processor systems.

This fixes t/op/threads.t to actually run test 4 instead of hanging.

-John
wb8tyw@qsl.net
Personal Opinion Only

Craig A. Berry
*nix forums Guru Wannabe

Joined: 27 May 2005
Posts: 143

Posted: Thu Mar 16, 2006 1:13 pm Post subject: Note

Re: Fix identified for OpenVMS threaded Perl hangs.

At 7:02 AM -0500 3/16/06, John E. Malmberg wrote:

Quote:

I have found that the link command for executables needs to be changed for threaded Perl build. The additional qualifiers are ignored for shared images.

I am not sure how to modify configure.com and descrip.mms_template etc to do this.

When building a threaded Perl, the link command should be:

$LINK :== LINK/THREADS_ENABLE=(MULTIPLE,UPCALLS)

Setting the above command before building Perl is the current work around that I am using.

The UPCALLS is needed to prevent calls to sleep(), SYS$HIBER(), usleep(), nanosleep(), and several other timed waits from becoming permanent.

The MULTIPLE allows the threaded Perl to take advantage of multi-processor systems.

This fixes t/op/threads.t to actually run test 4 instead of hanging.

Thanks for tracking this down. The "workaround" should be to simply
answer yes to the question:

Enable multiple kernel threads and upcalls?

at configuration time. We turn it off by default because there were
problems with these options when first released some years ago. We
should probably turn it on by default for VMS 7.2 and later, or maybe
7.3. One reason I've never done that is that I have only
single-processor systems to test on.
--
____________________________________________
Craig A. Berry
mailto:craigberry@mac.com

"Literary critics usually know what they're
talking about. Even if they're wrong."
-- Perl creator Larry Wall

John E. Malmberg
*nix forums Guru Wannabe

Joined: 30 May 2005
Posts: 264

Posted: Thu Mar 16, 2006 1:49 pm Post subject: Note

Re: Fix identified for OpenVMS threaded Perl hangs.

Craig A. Berry wrote:

Quote:

At 7:02 AM -0500 3/16/06, John E. Malmberg wrote:

I have found that the link command for executables needs to be
changed for threaded Perl build. The additional qualifiers are
ignored for shared images.

I am not sure how to modify configure.com and descrip.mms_template
etc to do this.

When building a threaded Perl, the link command should be:

$LINK :== LINK/THREADS_ENABLE=(MULTIPLE,UPCALLS)

Setting the above command before building Perl is the current work
around that I am using.

This fixes t/op/threads.t to actually run test 4 instead of hanging.

Thanks for tracking this down. The "workaround" should be to simply
answer yes to the question:

Enable multiple kernel threads and upcalls?

at configuration time. We turn it off by default because there were
problems with these options when first released some years ago. We
should probably turn it on by default for VMS 7.2 and later, or maybe
7.3. One reason I've never done that is that I have only
single-processor systems to test on.

I will look at configure.com then.

My recommendation is that if threads are enabled, upcalls should also be
enabled by default.

The multiple kernel threads can expose coding problems on a
multi-processor system, so enabling it as default may expose some problems.

If someone has a multi-processor system available to test on, then I
would recommend seeing if there are any problems with multiple kernel
threads enabled.

So for now, it may be safer to leave multiple kernel threads default to
be off.

-John
wb8tyw@qsl.net
Personal Opinion Only

Craig A. Berry
*nix forums Guru Wannabe

Joined: 27 May 2005
Posts: 143

Posted: Thu Mar 16, 2006 2:24 pm Post subject: Note

Re: Fix identified for OpenVMS threaded Perl hangs.

At 8:49 AM -0500 3/16/06, John E. Malmberg wrote:

Quote:

Craig A. Berry wrote:
At 7:02 AM -0500 3/16/06, John E. Malmberg wrote:

I have found that the link command for executables needs to be
changed for threaded Perl build. The additional qualifiers are
ignored for shared images.

I am not sure how to modify configure.com and descrip.mms_template
etc to do this.

When building a threaded Perl, the link command should be:

$LINK :== LINK/THREADS_ENABLE=(MULTIPLE,UPCALLS)

Setting the above command before building Perl is the current work
around that I am using.

This fixes t/op/threads.t to actually run test 4 instead of hanging.
Thanks for tracking this down. The "workaround" should be to simply
answer yes to the question:

Enable multiple kernel threads and upcalls?

at configuration time. We turn it off by default because there were
problems with these options when first released some years ago. We
should probably turn it on by default for VMS 7.2 and later, or maybe
7.3. One reason I've never done that is that I have only
single-processor systems to test on.

I will look at configure.com then.

I may have spoken too soon. It looks like this option only affects
compiling, not linking, so there may be a bit more configuration work
to do.

Quote:

My recommendation is that if threads are enabled, upcalls should also be enabled by default.

The multiple kernel threads can expose coding problems on a multi-processor system, so enabling it as default may expose some problems.

If someone has a multi-processor system available to test on, then I would recommend seeing if there are any problems with multiple kernel threads enabled.

So for now, it may be safer to leave multiple kernel threads default to be off.

OK, I suspect we'll have work to do to make things genuinely
thread-safe, as I doubt this has ever been stress tested. I have the
beginnings of a patch for our homegrown pipe implementation that
tries to enhance thread safety.

--
____________________________________________
Craig A. Berry
mailto:craigberry@mac.com

"Literary critics usually know what they're
talking about. Even if they're wrong."
-- Perl creator Larry Wall

John E. Malmberg
*nix forums Guru Wannabe

Joined: 30 May 2005
Posts: 264

Posted: Sat Mar 18, 2006 3:10 am Post subject: Note

Re: Fix identified for OpenVMS threaded Perl hangs.

Craig A. Berry wrote:

Quote:

At 8:49 AM -0500 3/16/06, John E. Malmberg wrote:

OK, I suspect we'll have work to do to make things genuinely
thread-safe, as I doubt this has ever been stress tested. I have the
beginnings of a patch for our homegrown pipe implementation that
tries to enhance thread safety.

Well, I found a wrinkle. With link/threads=upcalls, two tests are
failing with ASTFLT. I can not isolate where the failures are as they
show up in different places.

%CMA-F-EXCCOP, exception raised; VMS condition code follows
-SYSTEM-F-ASTFLT, AST fault, SP=00000000, param=00000000,
PC=0000000000000000, PS=00000000, target PC=FFFFFFFF8136DF54, PS=0000001B

t/op/alarm............................FAILED--no leader found
ext/Time/HiRes/t/HiRes................FAILED--expected 33 tests, saw 11

I will ask some people that know more about threads than I do next week.

-John
wb8tyw@qsl.net
Personal Opinion Only

John E. Malmberg
*nix forums Guru Wannabe

Joined: 30 May 2005
Posts: 264

Posted: Mon Mar 20, 2006 5:38 pm Post subject: Note

Re: Fix identified for OpenVMS threaded Perl hangs.

John E. Malmberg wrote:

Quote:

Craig A. Berry wrote:

At 8:49 AM -0500 3/16/06, John E. Malmberg wrote:

OK, I suspect we'll have work to do to make things genuinely
thread-safe, as I doubt this has ever been stress tested. I have the
beginnings of a patch for our homegrown pipe implementation that
tries to enhance thread safety.

Well, I found a wrinkle. With link/threads=upcalls, two tests are
failing with ASTFLT. I can not isolate where the failures are as they
show up in different places.

%CMA-F-EXCCOP, exception raised; VMS condition code follows
-SYSTEM-F-ASTFLT, AST fault, SP=00000000, param=00000000,
PC=0000000000000000, PS=00000000, target PC=FFFFFFFF8136DF54, PS=0000001B

t/op/alarm............................FAILED--no leader found
ext/Time/HiRes/t/HiRes................FAILED--expected 33 tests, saw 11

I will ask some people that know more about threads than I do next week.

This is a known issue with Posix Threads that is fixed with
VMS821I_PTHREAD-V0100 for v8.2-1 Integrity and is expected to soon be
available for V8.2 Alpha in patch VMS82A_PTHREAD-V0100.

-John
wb8tyw@qsl.net
Personal Opinion Only

John E. Malmberg
*nix forums Guru Wannabe

Joined: 30 May 2005
Posts: 264

Posted: Mon Mar 20, 2006 5:45 pm Post subject: Note

Re: Fix identified for OpenVMS threaded Perl hangs.

Craig A. Berry wrote:

Quote:

At 8:49 AM -0500 3/16/06, John E. Malmberg wrote:

Craig A. Berry wrote:

At 7:02 AM -0500 3/16/06, John E. Malmberg wrote:

I have found that the link command for executables needs to be
changed for threaded Perl build. The additional qualifiers are
ignored for shared images.

I am not sure how to modify configure.com and descrip.mms_template
etc to do this.

When building a threaded Perl, the link command should be:

$LINK :== LINK/THREADS_ENABLE=(MULTIPLE,UPCALLS)

Setting the above command before building Perl is the current work
around that I am using.

This fixes t/op/threads.t to actually run test 4 instead of hanging.

Thanks for tracking this down. The "workaround" should be to simply
answer yes to the question:

Enable multiple kernel threads and upcalls?

at configuration time. We turn it off by default because there were
problems with these options when first released some years ago. We
should probably turn it on by default for VMS 7.2 and later, or maybe
7.3. One reason I've never done that is that I have only
single-processor systems to test on.

I will look at configure.com then.

I may have spoken too soon. It looks like this option only affects
compiling, not linking, so there may be a bit more configuration work
to do.

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.

I do not see how it changes the linker behavior for other images with
main() modules that link against perlshr.

I also notice that the configure.com procedure is able to configure some
types of threaded build options that there no longer is a way to build.

Also as I noted with my patch to thread.h, more stack is needed for
posix threads.

-John
wb8tyw@qsl.net
Personal Opinion Only

Craig A. Berry
*nix forums Guru Wannabe

Joined: 27 May 2005
Posts: 143

Posted: Tue Mar 21, 2006 1:09 pm Post subject: Note

Re: Fix identified for OpenVMS threaded Perl hangs.

At 12:45 PM -0500 3/20/06, John E. Malmberg wrote:

< discussion of kernel threads and upcalls snipped >

Quote:

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.

Quote:

I do not see how it changes the linker behavior for other images with main() modules that link against perlshr.

Unless you're building an embedded Perl (as, for example, with
mod_perl), you're unlikely to have another main() module.

Quote:

I also notice that the configure.com procedure is able to configure some types of threaded build options that there no longer is a way to build.

Yes, I'm sure there is some clean-up to be done there.

Quote:

Also as I noted with my patch to thread.h, more stack is needed for
posix threads.

Just applied this as #27563.
--
____________________________________________
Craig A. Berry
mailto:craigberry@mac.com

"Literary critics usually know what they're
talking about. Even if they're wrong."
-- Perl creator Larry Wall

Craig A. Berry
*nix forums Guru Wannabe

Joined: 27 May 2005
Posts: 143

Posted: Thu Mar 23, 2006 11:59 pm Post subject: Note

Re: Fix identified for OpenVMS threaded Perl hangs.

At 7:09 AM -0600 3/21/06, Craig A. Berry wrote:

Quote:

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:craigberry@mac.com

"Literary critics usually know what they're
talking about. Even if they're wrong."
-- Perl creator Larry Wall

PPrymmer@factset.com
*nix forums beginner

Joined: 08 Jul 2005
Posts: 21

Posted: Fri Mar 24, 2006 3:39 am Post subject: Note

Re: Fix identified for OpenVMS threaded Perl hangs.

"Craig A. Berry" <craigberry@mac.com> wrote on 03/23/2006 06:59:16 PM:

Quote:

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.

I am sorry I have not replied to the previous message in this thread.
What multi processor testing would you like to see done with
which confiure.com parameters? I'll try to do some testing.

Peter Prymmmer

PPrymmer@factset.com
*nix forums beginner

Joined: 08 Jul 2005
Posts: 21

Posted: Sat Mar 25, 2006 3:31 am Post subject: Note

Re: Fix identified for OpenVMS threaded Perl hangs.

"Craig A. Berry" <craigberry@mac.com> wrote on 03/23/2006 11:04:07 PM:

Quote:

blead with

$ @configure -"Dusedevel" -"Dusethreads" -"Dusekernelthreads" -"des"

should give us some indication of how thread-safe we are (or are not).

bleed at 27596
HP C V7.1-011 on OpenVMS IA64 V8.2-1
16 way rx8620 (1.60GHz/6.0MB) IA64
`mmk test` turned up the following FAILED:

ext/POSIX/t/sigaction......................................FAILED at test
10
lib/ExtUtils/t/basic.......................................FAILED at test
28
lib/ExtUtils/t/FIRST_MAKEFILE..............................FAILED at test
5
lib/ExtUtils/t/INSTALL_BASE................................FAILED at test
5
lib/ExtUtils/t/Manifest....................................FAILED at test
26
lib/ExtUtils/t/oneliner....................................FAILED at test
4
lib/Module/Build/t/basic...................................FAILED--expected
55 tests, saw 13
lib/Module/Build/t/destinations............................FAILED--expected
92 tests, saw 34
lib/Module/Build/t/ext.....................................FAILED at test
92
lib/Module/Build/t/extend..................................FAILED at test
6
lib/Module/Build/t/files...................................FAILED--expected
6 tests, saw 2
lib/Module/Build/t/install.................................FAILED at test
5
lib/Module/Build/t/manifypods..............................FAILED--expected
21 tests, saw 2
lib/Module/Build/t/metadata................................FAILED--expected
46 tests, saw 8
lib/Module/Build/t/metadata2...............................FAILED--expected
18 tests, saw 4
lib/Module/Build/t/ppm.....................................FAILED--expected
12 tests, saw 1
lib/Module/Build/t/runthrough..............................FAILED at test
13
lib/Module/Build/t/tilde...................................FAILED--expected
11 tests, saw 0
lib/Module/Build/t/xs......................................FAILED at test
3
lib/Net/Ping/t/510_ping_udp................................FAILED at test
2

as well as this summary:

Failed 20 test scripts out of 1150, 98.26% okay.
### Since not all tests were successful, you may want to run some of
### them individually and examine any diagnostic messages they produce.
### See the INSTALL document's section on "make test".
### You have a good chance to get more information by running
### ./perl harness
### in the 't' directory since most (>=80%) of the tests succeeded.
u=60.67 s=0.00 cu=0.00 cs=0.00 scripts=1150 tests=161041

I hope that helps (I may be able to do some multi AXP tests too).

Peter Prymmer

Google

Display posts from previous:

Page 1 of 1 [11 Posts]

View previous topic :: View next topic

The time now is Wed Dec 03, 2008 2:29 am | All times are GMT

Forum index » Not Unix » VMS » vmsperl

Jump to:

Topic		Author	Forum	Replies	Last Post
Similar Topics
	Need Help with Program in Perl on a Netware Server	fhadzocos@gmail.com	Perl	3	Fri Jul 21, 2006 1:57 pm
	problems using oddmuse with mod_perl2 inside apache2.2 pe...	Fergus McMenemie	Perl	0	Fri Jul 21, 2006 9:48 am
	Problem with Win32-SerialPort over bluetooth @ windows + ...	ctloh	Perl	0	Fri Jul 21, 2006 8:08 am
	Posting Guidelines for comp.lang.perl.misc (: 1....	Tad McClellan	Perl	0	Fri Jul 21, 2006 7:22 am
	Perl Help - easy one	Marc Perkel	Exim	2	Fri Jul 21, 2006 5:54 am

Remortgages | Peak Oil | Internet Advertising | Loans | Online Advertising

Other DeniX Solutions sites: Unix/Linux blog | electronics forum | medicine forum | science forum |

[ Time: 5.2556s ][ Queries: 16 (5.0726s) ][ GZIP on - Debug on ]