[racket] the benefactor in THREAD-RESUME

At Mon, 8 Nov 2010 01:31:45 +0000, Taylor R Campbell wrote:
>    Date: Sun, 7 Nov 2010 18:17:48 -0700
>    From: Matthew Flatt <mflatt at cs.utah.edu>
> 
>    So far, I don't think I've run into a case in practice where the second
>    argument to `thread-resume' wasn't `(current-thread)'.
> 
> What about a case of (thread-resume t (current-thread)) where t is not
> needed for more than a known dynamic extent or for one sync operation?
> Could every use be replaced by (with-thread-resumed t (lambda () ...))
> and (with-thread-resumed-evt t e)?  The latter would return an event,
> synchronizing which is equivalent to synchronizing e, except that t is
> allowed to run at least until the the sync operation commits to a
> rendezvous choice.

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.

For all the examples I can recall, though, the `sync's were all exposed
(always with channels), so I think `with-thread-resumed-evt' would be
fine.

FWIW, by "until the sync operation commits" I imagine you mean that if
the thread that called `sync' is itself suspended, then the resumed
thread might be suspended as well, even though the sync hasn't
committed --- and that's still ok for the cases I can think of.