[racket] Peekable asynchronous channel?

See kill safety paper. 


On Aug 12, 2013, at 6:40 PM, Robby Findler wrote:

> Guys: the main thing to keep in mind when programming with CML is that you can jut build your own sync abstractions easily. 
> 
> 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.
> 
> Don't just rely on the built in abstractions tho!
> 
> On Monday, August 12, 2013, Hendrik Boom wrote:
> 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:
> >                     http://barzilay.org/                   Maze is Life!
> > ____________________
> >   Racket Users list:
> >   http://lists.racket-lang.org/users
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130812/f7256167/attachment.html>