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 <mfl...@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. > >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
