[racket-dev] Master-Worker with Places

At Thu, 29 Mar 2012 12:00:07 -0600, Nick Shelley wrote:
> I think it would make more sense for the result of syncing on a
> place-channel to return the channel itself as a result. This would make an
> explicit call to place-channel-get necessary, which may be a downside, but
> the upside is I could then put something on the same channel or do whatever
> else I may want with it.

If syncing on a place channel doesn't return the available value, then
it's possible for a different client to consume the value before a
later `place-channel-get'. Besides the further complexity that adds,
there are issues of fair scheduling.

If you want the place channel back, you how about wrapping it so that
the result combines the value with its place channel?

 (wrap-evt pc (lambda (v) (cons pc v)))

Or, if the reason to have the place channel is to reply, then it might
make sense to put the reply in the wrapping procedure:

 (wrap-evt pc (lambda (v) 
                (channel-put pc (derive-some-answer v))))


> As a sort of side note, it would be nice to be able to treat this problem
> similar to a user thread problem where you can conceptually imagine having
> infinite workers and just giving one chunk of work to each of them. I tried
> to do this at first, but because of the way places are implemented, I ran
> out of file descriptors relatively quickly (and the overhead of starting a
> new VM for each chunk of work might have been too much anyway, I don't
> know). I don't know if an abstraction like that is possible or useful in
> general, but it may be something to consider.

I agree that we need more abstractions built on top of places.