[racket-dev] Master-Worker with Places

Thanks, that is helpful. I think I had read about wrap-evt but didn't know
how I would use it. Those examples help.

I guess my email should have been a question to the users group about how I
could do it better rather than a suggestion to the dev group about what to
change.

On Thu, Mar 29, 2012 at 12:14 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20120329/48b7c135/attachment.html>