On 2011-10-22 9:43 AM, Tony Garnock-Jones wrote:
> Nothing like the 20 seconds or so after a post to make one question
> oneself. Could it be that semaphore-peek-evt could be used to get what I
> need? I'll experiment.
The answer is "almost", i.e. "no". But scheme_sema_post_all doesn't do
what I want either. And I don't think having a thread issue an infinite
sequence of (channel-put)s can be used either. I think I need something
else. Something primitive, maybe.
- If I use semaphore-peek-evt or scheme_sema_post_all, I still have a
problem with kill safety, because I have to do something like:
(when (semaphore-try-wait? (blocking-box-used b))
(set-blocking-box-cell! b the-value)
(semaphore-post (blocking-box-ready b)))
...which might be killed between the try-wait and the post.
- If I use a thread issuing an infinite sequence of channel-puts,
(thread (lambda ()
(when (semaphore-try-wait? (blocking-box-used b))
(let loop ()
(channel-put c v)
(loop)))))
...the custodian could be shut down at some point. Trying the same
trick as the buffered async channels doesn't work here, because I'd
need to know which thread to thread-resume when I checked the box's
value, and to do that I'd need a kill-safe box that can be written
into only once, which is an infinite regress.
It looks like I need something like a cross between CAS and a semaphore.
Perhaps I'm having imagination failure here. Is there something I'm
overlooking that would get me an event to wait on until a value arrives,
and that enforces that second and subsequent value-setting attempts do
not succeed?
(This is closely related to E's Promises and less closely related to
Scheme's delay/force.)
Regards,
Tony
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
