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 <schus...@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 <e...@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 > >
____________________ Racket Users list: http://lists.racket-lang.org/users
