On Tue, 8 Aug 2000 22:49:13 -0400, John Tobey wrote:
>As has been mentioned on a nearby subthread, we're probably just going
>to store the function call stack, not top-level variables or code.
That doesn't sound useful, at all.
For example:
sub foo {
my($x, $y) = @_;
bar(2*$x, $x+$y);
print $x, $y;
}
sub bar {
...
continuation; # stop and restore to this point;
...
}
When bar returns, the values of $x and $y will simply be lost.
I can live with files that all have been closed, database connections
that have been lost, etc. But *all* variables reset, global and lexical?
You'll get a pretty useless system, then.
--
Bart.
- Re: RFC 47 (v1) Universal Asynchronous I/O John Tobey
- Re: RFC 47 (v1) Universal Asynchronous I/O Uri Guttman
- Re: RFC 47 (v1) Universal Asynchronous I/O Bryan C . Warnock
- Re: RFC 47 (v1) Universal Asynchronous I/O Bart Lateur
- Re: RFC 47 (v1) Universal Asynchronous I/O John Tobey
- Re: RFC 47 (v1) Universal Asynchronous I/O Bart Lateur
- Re: RFC 47 (v1) Universal Asynchronous ... Piers Cawley
- Re: RFC 47 (v1) Universal Asynchronous ... John Tobey
- Re: RFC 47 (v1) Universal Asynchro... Piers Cawley
- Re: RFC 47 (v1) Universal Asynchro... John Tobey
- Re: RFC 47 (v1) Universal Asynchro... Bart Lateur
- Re: RFC 47 (v1) Universal Asynchronous I/O Buddha Buck
- Re: RFC 47 (v1) Universal Asynchronous I/O John Tobey
- Re: RFC 47 (v1) Universal Asynchronous I/O Ken Fox
- Re: RFC 47 (v1) Universal Asynchronous I/O Bart Lateur
