In my limited experience with parallel computing, it seems like the
master-worker paradigm is somewhat common. However, it seems like Racket's
places (or at least the way events are done with place-channels) makes this
inconvenient. Since there is nothing that I can find in the result of
syncing on a place-channel that would allow me to then send some new work
to the same channel, I have to implement this manually by having each
channel keep track of it's place in the list of workers and send that
information explicitly. This approach seems hacky and more prone to bugs.
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 changing how place-channel events are treated isn't feasible, I think it
would at least be useful to provide an abstraction that makes master-worker
more convenient. One idea might be a sync-channel function that returns the
channel.
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.
-Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20120329/0a67a462/attachment.html>