Thanks very much for the quick workaround (and ultimately for the repair) — 
it's always a relief to know I haven't overlooked some detail!

On Monday, November 14, 2016 at 9:30:17 AM UTC-6, Matthew Flatt wrote:
> No, that's not supposed to happen. I've pushed a repair.
> 
> 
> I was able to replicate the problem on Mac OS X, and it looks like the
> problem with filesystem events is specific to that platform. But the
> filesystem-event problem is due to a more general bug in the scheduler,
> and the same bug shows up with
> 
>    (sync (wrap-evt s (lambda (v) 'ok)))
> 
> on all platforms.
> 
> The problem is related to `thread-suspend`, a semaphore becoming ready
> while the thread is suspended, and having a wrapper (in the sense of
> `wrap-evt`) around the semaphore. That pattern happens internally with
> filesystem events on Mac OS X. I think `thread-suspend` probably isn't
> used that much, which would explain how this scheduler bug survived for
> so long.
> 
> 
> You can work around the bug by creating a dummy pipe and waiting for
> the input end of the pipe in addition to the filesystem event, like
> this:
> 
>    (define-values (dummy-i dummy-o) (make-pipe))
>    (sync dummy-i (wrap-evt s (lambda (v) 'ok)))
> 
> Having a pipe in the set of events sends the scheduler into a path that
> doesn't have the bug.
> 
> 
> At Sun, 13 Nov 2016 17:43:43 -0800 (PST), Philip McGrath wrote:
> > Hi everyone,
> > 
> > I've been trying to get to know Racket's threads and particularly 
> > filesystem-change-evt, and I've come to a point of confusion. I thought 
> > that a 
> > filesystem-change-evt's synchronization result was supposed to be the event 
> > itself, which it is most of the time, but in combination with 
> > thread-suspend 
> > it seems to produce #f, and I'm not sure why.
> > 
> > Here's a tiny example:
> > 
> > > (define t
> >        (thread (λ ()
> >                        (println (sync (filesystem-change-evt "test"))))))
> > > (thread-suspend t)
> > ;; at this point I go and do something like "echo foo >test"
> > > (thread-resume t)
> > ;; prints #f
> > 
> > Is this supposed to happen?
> > 
> > What's particularly confusing is that the same thing happens (i.e. #f is 
> > printed) if I instead define t to be:
> > 
> > (thread
> >    (λ ()
> >      (println
> >        (sync (wrap-evt (filesystem-change-evt "test")
> >                                    (λ (x) 'my-result))))))
> > 
> > Does anyone know what's going on?
> > 
> > Thanks,
> > Philip
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups 
> > "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to