In my limited experience with parallel computing, it seems like the master-worker paradigm is somewhat common. However, it seems like Racket&#39;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&#39;s place in the list of workers and send that information explicitly. This approach seems hacky and more prone to bugs.<div>

<br></div><div>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.</div>

<div><br></div><div>If changing how place-channel events are treated isn&#39;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.</div>

<div><br></div><div>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&#39;t know). I don&#39;t know if an abstraction like that is possible or useful in general, but it may be something to consider.</div>

<div><br></div><div>-Nick</div>