Craig A. Berry wrote:
At 11:07 PM -0500 11/18/06, John E. Malmberg wrote:
--- /rsync_root/perl/lib/perl5db.pl     Sat Jul  8 13:56:37 2006
+++ lib/perl5db.pl      Sat Nov 18 17:49:05 2006
@@ -1317,9 +1317,21 @@
   # We're a child. Make us a label out of the current PID structure
   # recorded in PERLDB_PIDS plus our (new) PID. Mark us as not having
   # a term yet so the parent will give us one later via resetterm().
-    $pids = "[$ENV{PERLDB_PIDS}]";
-    $ENV{PERLDB_PIDS} .= "->$$";
-    $term_pid = -1;
+
+    my $env_pids = $ENV{PERLDB_PIDS};
+    $pids = "[$env_pids]";
+
+    # Unless we are on OpenVMS, all programs under the DCL shell run under
+    # the same PID.
+
+    if (($^O eq 'VMS') && ($env_pids =~ /\b$$\b/)) {
+        $term_pid         = $$;


What I think this is saying is that if the pid of the current process
is in the list, then consider ourselves the parent and do not add
ourselves to the list.  It seems to me these two things should be
separated and clarified:

1.)  If the current process matches the *first* element in the list,
take that as an "I am the parent" indication equivalent to the
nonexistence of $ENV{PERLDB_PIDS}.  One way to do that would be to
add a check before the current logic in which we simply clobber
$ENV{PERLDB_PIDS} in this case, and then let the current logic
continue to function as is.

A duplicate PID should only show up as the last element in the list. I coded the patch to handle a general match.

2.)  Never add a pid to the list if it already exists, perhaps
issuing a warning if we do see a duplicate.

Perl is already generating quite a verbose warning about the debugger being forked.

+    }
+    else {
+        $ENV{PERLDB_PIDS} .= "->$$";
+        $term_pid = -1;
+    }
+
} ## end if (defined $ENV{PERLDB_PIDS...
else {
Go ahead and take another crack at the patch if you want to.

I will look at this some more in a bit.

BTW, the reason the new lib/perl5db.t test is failing on VMS is, as
far as I can tell, unrelated.  It appears at first blush that the TTY
override is not working and it is waiting for input from the console
that it never gets.

I will look at that some more. Right now, I am working on a hack to make things work better when the debugger really is "forked" on VMS so that it is easier to use.

-John
[EMAIL PROTECTED]
Personal Opinion Only

--
Need a senior system engineer?  I am looking for employment.
http://encompasserve.org/~malmberg/MALMBERG_CS1_RESUME.TXT

Reply via email to