Am Samstag, 12. August 2006 17:55 schrieb Bob Rogers:
>From: Leopold Toetsch <[EMAIL PROTECTED]>
>See "Method Overloading and GC Issues" in Cfunc.pod. The only way
>IMHO to avoid this problem is to run GC at "safe" points at the
>runloop level . . .
>
> Had you considered keeping t
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Wed, 9 Aug 2006 14:00:19 +0200
The continuation barrier is only one nastyness of inferior runloops. The
second problem with it is that it heavily influences the guts of garbage
collection . . .
See "Method Overloading and GC Issu
Am Sonntag, 6. August 2006 17:20 schrieb Bob Rogers:
>The problem is that inferior runloops cannot be re-entered via
> continuation. One example (out of many) is the delegate pmclass, which
> uses inferior runloops in vtable methods to run bytecode. The resulting
> call structure (mixing byte
Bob Rogers wrote:
There are two broad solutions:
1. Restrict continuations to move only "outward", which makes it
unnecessary to restart inferior runloops. This may not be as bad as it
seems, as most of the languages I can think of can be implemented using
only outward (returning) conti
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Tue, 8 Aug 2006 19:43:31 +0200
Am Sonntag, 6. August 2006 17:20 schrieb Bob Rogers:
[ a much more detailed answer will follow ]
> ? ?The problem is that inferior runloops cannot be re-entered via
> continuation. ?
C is an exce
Am Sonntag, 6. August 2006 17:20 schrieb Bob Rogers:
[ a much more detailed answer will follow ]
> The problem is that inferior runloops cannot be re-entered via
> continuation.
C is an excellent example for the POC. I've a first question
though: assuming that we might want to eliminate in
