[racket] Peekable asynchronous channel?

I think that would be this paper by Robby and Matthew:

https://www.cs.utah.edu/plt/kill-safe/

(A DuckDuckGo or Google search for "kill safety Racket" yields an
amusingly alarming variety of other results.)

On Mon, Aug 12, 2013 at 6:44 PM, Matthias Felleisen
<matthias at ccs.neu.edu> wrote:
>
> 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
>
>
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>