[racket] Peekable asynchronous channel?

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.)

Robby


On Tue, Aug 13, 2013 at 9:48 AM, Jonathan Schuster <schuster at ccs.neu.edu>wrote:

> 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.
>
> 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.
>
> Thanks again.
>
>
> On Mon, Aug 12, 2013 at 6:52 PM, Eli Barzilay <eli at barzilay.org> wrote:
>
>> An hour ago, 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.
>>
>> The point is that the wrapper reads as usual, and it implements the
>> peeking -- so in the wrapper there is no need to release the the
>> value.
>>
>>
>> 10 minutes ago, 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!
>>
>> Yes -- that.
>>
>> --
>>           ((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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130813/d93f21cc/attachment-0001.html>