At Fri, 14 Dec 2012 09:15:48 +0100, Tobias Hammer wrote: > On Fri, 14 Dec 2012 07:25:36 +0100, David T. Pierson <d...@mindstory.com> > wrote: > > > I've wondered about this. What is the rational behind these > > differences? Wrapping events is cumbersome. > > > > For instance, my first intuition is that the synchronization result of a > > place channel would be the place channel itself, just like the > > synchronization result of a thread is the thread itself. Why aren't > > these analogous? > > I would guess it prevents race-conditions. Channels and place-channels may > be accessed from any number of threads, and therefore it would be possible > that the data on the channel is removed between the sync and the > *-get-call. Thread channels are different in that it's guaranteed that > only one thread can access them. > Input-ports for example suffer from these races and the user has to make > sure to prevent or handle the them correctly.
Right. I'll add that the intended pattern is not (define r (sync (handle-evt e1 (lambda (v) (cons 1 v))) (handle-evt e2 (lambda (v) (cons 2 v))))) (match r [(cons 1 v) ... handle e1 result ...] [(cons 2 v) ... handle e2 result ...]) but instead (sync (handle-evt e1 (lambda (v) ... handle e1 result ...)) (handle-evt e2 (lambda (v) ... handle e2 result ...))) This pattern works even if you want to continue a loop after handling an event, since the function in a `handle-evt' is called in tail position with respect to the `sync'. The Guide needs a chapter on concurrency. Racket's approach to synchronization is from Concurrent ML, so if you're interested in the design rationale, then see _Concurrent Programming in ML_ by John Reppy. Some examples in Racket notation can be found in a paper about "kill safety": http://www.cs.utah.edu/plt/publications/pldi04-ff.pdf ____________________ Racket Users list: http://lists.racket-lang.org/users