<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>See kill safety paper. </div><div><br></div><br><div><div>On Aug 12, 2013, at 6:40 PM, Robby Findler wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Guys: the main thing to keep in mind when programming with CML is that you can jut build your own sync abstractions easily. <div><br></div><div>In this case you would have a separate thread that mediates all access to one of these channels and that makes it easy to get such concerns right.</div>
<div><br></div><div>Don't just rely on the built in abstractions tho!<span></span><br><br>On Monday, August 12, 2013, Hendrik Boom wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 to<br>
let independent threads peek the same element and decie they do want<br>
it?<br>
<br>
There's got to be some kind of rejecting release if a peek holds the<br>
stream until accepted.<br>
<br>
-- hendrik<br>
<br>
><br>
><br>
> 10 minutes ago, Jonathan Schuster wrote:<br>
> > I discussed this with Vincent and Asumu today in person. Here are<br>
> > some of the results of our conversation:<br>
> ><br>
> > What I really want is a function like<br>
> > "async-channel-non-empty-event" that returns an event that's ready<br>
> > for synchronization when async-channel-get would not block (but the<br>
> > event does not consume a message). The predicate<br>
> > async-channel-empty? could also be useful for similar reasons.<br>
> ><br>
> > The naive implementation of a peek event doesn't work because of the<br>
> > following use case: On some thread (call it thread 1), the thread<br>
> > syncs on a peek event and gets the peeked value. Thread 1 decides it<br>
> > likes the value and attempts to pull it from the channel. However,<br>
> > at the same time another thread (thread 2) pulls out that value, so<br>
> > thread 1 ends up with a different value, which it doesn't know how<br>
> > to process. That use case needs a more complicated API that handles<br>
> > more of the thread synchronization. My own work doesn't involve this<br>
> > use case, though.<br>
> ><br>
> > For now, I'm going to write something to act like a channel with a<br>
> > non-empty event, but do people think async-channel-non-empty and<br>
> > async-channel-get would be useful to have in Racket proper? If not,<br>
> > would there be interest in providing that functionality as a<br>
> > package?<br>
><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>
> Racket Users list:<br>
> <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
</blockquote></div>
____________________<br> Racket Users list:<br> <a href="http://lists.racket-lang.org/users">http://lists.racket-lang.org/users</a><br></blockquote></div><br></body></html>