"Dulcimer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I find C<timeout(60) { ... }> too terse, and would
> rather see a more verbose version
I'm obviously more lazy than you ;-).
> Ah. Ok, but if that's the case, you could as easily write it
>
> timeout(5) { coro { ... } };
>
> and have the compiler build it accordingly. The same logic works either
> way from that end.
Given that its a macro, its probably true that I could do some up-front
manipulation like that. But its a lot more work than launching a thread.
However, given that it is a macro, we could eliminate the outer-curlies.
Lets see if I know how to write a macro...
macro timeout is parsed( rx:w/
$secs:= <Perl.expression>
$code_type := ( thread | coro )?
$code := <Perl.block>/)
{
$code_type eq "thread" and $code = "{ thread $code }";
"my \$$(Perl.tmpvarname) = Timer.new(secs=>$secs, code=>$code);"
}
timeout(60) coro { ... }
timeout(60) thread { ... }
timeout(60) { ... } # default is coro
Even if it works, I have a feeling that the macro has plenty of scope for
improvement.
> > Now here's another semantics question: would we want the following to
> > be valid?
> >
> > sub slow
> > {
> > timeout(60) { return undef but "Error: timed out" };
> > return slow_imp;
> > }
>
> Dunno....returns from a single routing that are in different threads
> could produce some real headaches.
>
> > How about:
> >
> > sub slow {
> > timeout(60) {
> > throw TimeoutException.new("Error: slow_fn timed out")
> > };
> > return slow_imp;
> > }
>
> I like thata lot better, but I'm still not sure how it would fly.
Actually, I think that both have pretty-much the same problems. I assume
@Dan could work out a way to get the mechanics to work (basically a mugging:
we kill a thread/coro and steal its continuation point). But the semantics
of the cleanup could cause a world of pain. But realistically, a common use
of a timeout is to kill something that's been going on too long. I suppose
we could require some level of cooperation the the "dead" code.
Dave.
