Thanks, that is helpful. I think I had read about wrap-evt but didn&#39;t know how I would use it. Those examples help.<div><br></div><div>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.<br>

<br><div class="gmail_quote">On Thu, Mar 29, 2012 at 12:14 PM, Matthew Flatt <span dir="ltr">&lt;<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">At Thu, 29 Mar 2012 12:00:07 -0600, Nick Shelley wrote:<br>
&gt; I think it would make more sense for the result of syncing on a<br>
&gt; place-channel to return the channel itself as a result. This would make an<br>
&gt; explicit call to place-channel-get necessary, which may be a downside, but<br>
&gt; the upside is I could then put something on the same channel or do whatever<br>
&gt; else I may want with it.<br>
<br>
</div>If syncing on a place channel doesn&#39;t return the available value, then<br>
it&#39;s possible for a different client to consume the value before a<br>
later `place-channel-get&#39;. Besides the further complexity that adds,<br>
there are issues of fair scheduling.<br>
<br>
If you want the place channel back, you how about wrapping it so that<br>
the result combines the value with its place channel?<br>
<br>
 (wrap-evt pc (lambda (v) (cons pc v)))<br>
<br>
Or, if the reason to have the place channel is to reply, then it might<br>
make sense to put the reply in the wrapping procedure:<br>
<br>
 (wrap-evt pc (lambda (v)<br>
                (channel-put pc (derive-some-answer v))))<br>
<div class="im"><br>
<br>
&gt; As a sort of side note, it would be nice to be able to treat this problem<br>
&gt; similar to a user thread problem where you can conceptually imagine having<br>
&gt; infinite workers and just giving one chunk of work to each of them. I tried<br>
&gt; to do this at first, but because of the way places are implemented, I ran<br>
&gt; out of file descriptors relatively quickly (and the overhead of starting a<br>
&gt; new VM for each chunk of work might have been too much anyway, I don&#39;t<br>
&gt; know). I don&#39;t know if an abstraction like that is possible or useful in<br>
&gt; general, but it may be something to consider.<br>
<br>
</div>I agree that we need more abstractions built on top of places.<br>
<br>
</blockquote></div><br></div>