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