[Chicken-hackers] [PATCH] Fix #1367 by using some black magic

[Peter Bex]

Hi all,

After some pondering I think I know what's going on in #1367.
When we enter (##sys#schedule), we simply fetch the suspended
thread's continuation (stored in a thunk) from the thread
structure and invoke it.

This invocation implicitly is done with the continuation that
would return in the old thread from the call to (##sys#schedule).
Of course, ##sys#schedule is not even _supposed_ to return, so
that makes no sense.  This continuation holds a reference to the
code that was active at the point where we called thread-start!,
which in the example program is running in the old thread (which
it also keeps a reference to).

Now, this example is a pathological case because all the threads
do is acquire a mutex and then fire off the next thread, after
which the thread is supposed to die.  The next thread does the
same and so on, resulting in a long chain of continuations that
goes all the way back to the primordial thread.

At least, I *think* that's what's going on.  Running the test
program with -:d shows a steady buildup of memory usage.
The fix is to call the thunk with an empty continuation.  We know
that it won't ever be invoked, so it doesn't matter what the
continuation does.  And of course we have the perfect fit for
that: ##sys#call-with-cthulhu!

I'm not sure if I would've come up with this if it wasn't for #1408...

Anyway, I hope this explanation makes sense.  It's a bit difficult to
explain this because it involves both the garbage collector _and_ the
scheduler.  Also, I'm not 100% sure about my analysis of the situation,
but the patch does seem to change the memory profile of the example
program to be completely steady.

IMO, this patch should go into both master and chicken-5.

Cheers,
Peter

0001-Threads-are-tricky-business.-We-must-sacrifice-a-goa.patch
Description: Text Data

signature.asc
Description: PGP signature