[racket] the benefactor in THREAD-RESUME

At Mon, 8 Nov 2010 02:38:02 +0000, Taylor R Campbell wrote:
>    Date: Sun, 7 Nov 2010 19:01:40 -0700
>    From: Matthew Flatt <mflatt at cs.utah.edu>
> 
>    Here's the only potential problem that I see offhand. Imagine that
>    there are multiple `sync' steps in communicating with `t'. The relevant
>    events for each `sync' must be protected using
>    `with-thread-resume-evt', which means that the programmer who is making
>    the current thread and `t' communicate must see all the relevant
>    `sync's. The `sync's can't be hidden inside some other abstraction.
> 
> If there are multiple rendezvous with thread t, shouldn't it be enough
> to use WITH-THREAD-RESUMED?

Sorry --- I got confused about `with-thread-resumed' versus
`with-thread-resumed-evt'. Yes, `with-thread-resumed' avoids that
potential problem.

> A little more generally, I wonder whether there are any situations in
> which a thread t suddenly decides that it must be a benefactor of
> another thread u for the rest t's life, or whether there is always a
> time beyond which t needn't care about u[*].

In all the practical examples that I've encountered, and I think you're
right that there was a point beyond which `t' needn't care about `u'.

> Also, I wonder whether
> there is any danger -- a hard-to-understand resource leak, say -- to
> t's being a benefactor longer than necessary.

Not in the examples that I've seen.