Guys: the main thing to keep in mind when programming with CML is that you can jut build your own sync abstractions easily. <div> </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> </div><div>Don't just rely on the built in abstractions tho! On Monday, August 12, 2013, Hendrik Boom wrote: <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: > An easy way to get around such things is to add a level of > indirection: wrap the original channel in another one where you > implement your own peeking. Once you peek, if you decde that's not what you want, might you want to let independent threads peek the same element and decie they do want it? There's got to be some kind of rejecting release if a peek holds the stream until accepted. -- hendrik > > > 10 minutes ago, Jonathan Schuster wrote: > > I discussed this with Vincent and Asumu today in person. Here are > > some of the results of our conversation: > > > > What I really want is a function like > > "async-channel-non-empty-event" that returns an event that's ready > > for synchronization when async-channel-get would not block (but the > > event does not consume a message). The predicate > > async-channel-empty? could also be useful for similar reasons. > > > > The naive implementation of a peek event doesn't work because of the > > following use case: On some thread (call it thread 1), the thread > > syncs on a peek event and gets the peeked value. Thread 1 decides it > > likes the value and attempts to pull it from the channel. However, > > at the same time another thread (thread 2) pulls out that value, so > > thread 1 ends up with a different value, which it doesn't know how > > to process. That use case needs a more complicated API that handles > > more of the thread synchronization. My own work doesn't involve this > > use case, though. > > > > For now, I'm going to write something to act like a channel with a > > non-empty event, but do people think async-channel-non-empty and > > async-channel-get would be useful to have in Racket proper? If not, > > would there be interest in providing that functionality as a > > package? > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > <a href="http://barzilay.org/" target="_blank">http://barzilay.org/</a> Maze is Life! > ____________________ > Racket Users list: > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> ____________________ Racket Users list: <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> </blockquote></div>