<div dir="ltr">You need a single thread that mediates access to the "peek state". It will be fine, and thread-safe if you do it that way and you can even make it kill-safe if you want. (You'll get a whole new set of channels for doing the communication.)<div> <br></div><div>Robby</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 13, 2013 at 9:48 AM, Jonathan Schuster <span dir="ltr"><<a href="mailto:schuster@ccs.neu.edu" target="_blank">schuster@ccs.neu.edu</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Thanks for the feedback, all. Wrapping the channel with my own custom logic was definitely the approach I was thinking about if I wrote it on my own, so I'm going forward with that.<br> <br></div> Having thought about it more, even without getting the peeked value this wrapper wouldn't be thread-safe: one thread could see a "non-empty" event, but then another thread reads the value immediately so that the first thread sees an empty channel when it goes to read the value. That forces me to conclude that even the "non-empty" event would not be of general use. Since I'm working with a single reader/single writer system, though, the wrapper approach will work for my purposes.<br> <br></div>Thanks again. <br></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Mon, Aug 12, 2013 at 6:52 PM, Eli Barzilay <span dir="ltr"><<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</a>></span> wrote:<br> </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div>An hour ago, Hendrik Boom wrote:<br> > On Mon, Aug 12, 2013 at 04:11:14PM -0400, Eli Barzilay wrote:<br> > > An easy way to get around such things is to add a level of<br> > > indirection: wrap the original channel in another one where you<br> > > implement your own peeking.<br> ><br> > Once you peek, if you decde that's not what you want, might you want<br> > to let independent threads peek the same element and decie they do<br> > want it?<br> ><br> > There's got to be some kind of rejecting release if a peek holds the<br> > stream until accepted.<br> <br> </div>The point is that the wrapper reads as usual, and it implements the<br> peeking -- so in the wrapper there is no need to release the the<br> value.<br> <div><br> <br> 10 minutes ago, Robby Findler wrote:<br> > Guys: the main thing to keep in mind when programming with CML is<br> > that you can jut build your own sync abstractions easily. <br> ><br> > In this case you would have a separate thread that mediates all<br> > access to one of these channels and that makes it easy to get such<br> > concerns right.<br> ><br> > Don't just rely on the built in abstractions tho!<br> <br> </div>Yes -- that.<br> </div></div><div><div><div><div class="h5"><br> --<br> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:<br> <a href="http://barzilay.org/" target="_blank">http://barzilay.org/</a> Maze is Life!<br> <br></div></div><div class="im"> ____________________<br> Racket Users list:<br> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br> </div></div></div></blockquote></div><br></div> <br>____________________<br> Racket Users list:<br> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br> <br></blockquote></div><br></div>