------- start of forwarded message -------
Path: csnews!boulder!agate!newsxfer.itd.umich.edu!news.mathworks.com!news.kei.com!news.ssd.intel.com!news.jf.intel.com!news.jf.intel.com!chrisj
From: chrisj@pdx044.intel.com (Chris Jones)
Newsgroups: comp.lang.perl.misc
Subject: Request for Perl internals info
Date: 29 Nov 1995 09:39:33 GMT
Organization: Intel Corporation
Lines: 100
Distribution: world
Message-ID: <CHRISJ.95Nov29013933@pdx044.intel.com>
NNTP-Posting-Host: pdx044.intel.com
I've been hacking out a module to allow me to do some sort of
cooperative multithreading in Perl. I've been able to get some
very basic threads switching back and forth, but before I spend the
next three weeks single-stepping in gdb, maybe somebody out there has
the knowledge and the time to answer some questions...
Although I'm trying NOT to modify the Perl source at all for this
project, if you don't know the Perl source code pretty well, then you
should probably hit 'n' now.
Also, I humbly pre-apologize if there is a better forum than this for
discussing Perl internals or if some of these questions have answers
out in netland somewhere that I haven't stumbled across.
Question #1
-----------
Does the following list comprise the perl state which needs to be
saved when switching from one task to the next. Global variables are
to be shared between threads, thus I don't want to use fork().
stack, retstack, scopestack, savestack, markstack, cxstack (and
the associated TOS pointers).
My thread switches are accomplished by calling a perl routine Switch()
which calls a C routine. The C routine swaps out/in the state
mentioned above and returns. Since the retstack has been swapped, the
perl routine returns to the LEAVESUB of the Switch() call from the
task which has just been swapped in. This seems to manage the curpad,
etc for the different contexts (?) OK (so far) except in the case
mentioned in Question #2.
[.Yes, I realize that my threading paradigm is quite basic, but it
suffices for a particular class of programs which I would like to
implement]
Question #2
-----------
Is there a way to prevent leave_scope from clearing out the lexically
scoped variables when a function returns? Related question: what is
the lifetime of a curpad entry (assuming I can keep leave_scope from
clearing the SVp*OK, etc flags in it).
Consider the following case:
$foo = 1;
&maybe_start_another_thread();
while (1) {
print("foo = $foo\n");
Thr::Switch(); # Switch saves current context and loads
} # "next" thread in line (round-robin)
sub maybe_start_another_thread {
my $bar = "Hello";
print("$bar works");
if (Thr::fork_me()) { # fork_me would save away current context
return; # so when caller calls Switch we come back
} # here (but return value would be 0)
while (1) {
$foo++;
print("$bar : $foo\n"); # Ack! $bar was invalidated by return
Thr::Switch();
}
}
Question #3
-----------
So far this has been an interesting academic exercise. Before I make
it a real project, can somebody tell me how I really should be doing
this?
Question #4
-----------
I found a mention in some archive that kap1@wimpy.cpe.uchicago.edu was
creating a perl internals reference, presumably lower level than the
perl{guts,call,api} pages. That address isn't valid anymore, but does
anybody know where I can find such a document?
Question #5
-----------
Does anybody have a good .gdbinit file which defines macros for
navigating stuff like: cxstack[cxstack_ix].cx_u.cx_blk.blk_u.blku_sub.cv?
Can it be added to the distribution?
Many thanks to anybody willing to help,
Ciao,
--
--Chris
+-------------------------------+---------------------------------+
| Chris S Jones, Intel Corp. : chrisj@ichips.intel.com |
| 2111 N.E. 25th, JF1-19 : (503) 264-4022 |
| Hillsboro, OR 97124 : #include <std.disclaimer> |
+-------------------------------+---------------------------------+
------- end of forwarded message -------
--
Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.com
: 1. What is the possibility of this being added in the future?
In the near future, the probability is close to zero. In the distant
future, I'll be dead, and posterity can do whatever they like... :-) --lwall
Path: csnews!boulder!agate!newsxfer.itd.umich.edu!news.mathworks.com!news.kei.com!news.ssd.intel.com!news.jf.intel.com!news.jf.intel.com!chrisj
From: chrisj@pdx044.intel.com (Chris Jones)
Newsgroups: comp.lang.perl.misc
Subject: Request for Perl internals info
Date: 29 Nov 1995 09:39:33 GMT
Organization: Intel Corporation
Lines: 100
Distribution: world
Message-ID: <CHRISJ.95Nov29013933@pdx044.intel.com>
NNTP-Posting-Host: pdx044.intel.com
I've been hacking out a module to allow me to do some sort of
cooperative multithreading in Perl. I've been able to get some
very basic threads switching back and forth, but before I spend the
next three weeks single-stepping in gdb, maybe somebody out there has
the knowledge and the time to answer some questions...
Although I'm trying NOT to modify the Perl source at all for this
project, if you don't know the Perl source code pretty well, then you
should probably hit 'n' now.
Also, I humbly pre-apologize if there is a better forum than this for
discussing Perl internals or if some of these questions have answers
out in netland somewhere that I haven't stumbled across.
Question #1
-----------
Does the following list comprise the perl state which needs to be
saved when switching from one task to the next. Global variables are
to be shared between threads, thus I don't want to use fork().
stack, retstack, scopestack, savestack, markstack, cxstack (and
the associated TOS pointers).
My thread switches are accomplished by calling a perl routine Switch()
which calls a C routine. The C routine swaps out/in the state
mentioned above and returns. Since the retstack has been swapped, the
perl routine returns to the LEAVESUB of the Switch() call from the
task which has just been swapped in. This seems to manage the curpad,
etc for the different contexts (?) OK (so far) except in the case
mentioned in Question #2.
[.Yes, I realize that my threading paradigm is quite basic, but it
suffices for a particular class of programs which I would like to
implement]
Question #2
-----------
Is there a way to prevent leave_scope from clearing out the lexically
scoped variables when a function returns? Related question: what is
the lifetime of a curpad entry (assuming I can keep leave_scope from
clearing the SVp*OK, etc flags in it).
Consider the following case:
$foo = 1;
&maybe_start_another_thread();
while (1) {
print("foo = $foo\n");
Thr::Switch(); # Switch saves current context and loads
} # "next" thread in line (round-robin)
sub maybe_start_another_thread {
my $bar = "Hello";
print("$bar works");
if (Thr::fork_me()) { # fork_me would save away current context
return; # so when caller calls Switch we come back
} # here (but return value would be 0)
while (1) {
$foo++;
print("$bar : $foo\n"); # Ack! $bar was invalidated by return
Thr::Switch();
}
}
Question #3
-----------
So far this has been an interesting academic exercise. Before I make
it a real project, can somebody tell me how I really should be doing
this?
Question #4
-----------
I found a mention in some archive that kap1@wimpy.cpe.uchicago.edu was
creating a perl internals reference, presumably lower level than the
perl{guts,call,api} pages. That address isn't valid anymore, but does
anybody know where I can find such a document?
Question #5
-----------
Does anybody have a good .gdbinit file which defines macros for
navigating stuff like: cxstack[cxstack_ix].cx_u.cx_blk.blk_u.blku_sub.cv?
Can it be added to the distribution?
Many thanks to anybody willing to help,
Ciao,
--
--Chris
+-------------------------------+---------------------------------+
| Chris S Jones, Intel Corp. : chrisj@ichips.intel.com |
| 2111 N.E. 25th, JF1-19 : (503) 264-4022 |
| Hillsboro, OR 97124 : #include <std.disclaimer> |
+-------------------------------+---------------------------------+
------- end of forwarded message -------
--
Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.com
: 1. What is the possibility of this being added in the future?
In the near future, the probability is close to zero. In the distant
future, I'll be dead, and posterity can do whatever they like... :-) --lwall