Re: [racket-dev] Kill-safe, single-write, blocking box (was Re: scheme_sema_post_all)

2011-10-22 Thread Tony Garnock-Jones
On 2011-10-22 11:42 AM, Matthew Flatt wrote:
> I think you could get this behavior by creating a manager thread when
> you create the new kind of box. If threads are too heavyweight, though,
> you can get the effect of a primitive by using `ffi/unsafe/atomic'.

Of course! Using a thread to manage the cell is straightforward and will
obviously work. I guess my imagination failed me indeed!

Thanks for the pointer to ffi/unsafe/atomic. I'll see if something
interesting can be done with that, as well.

Regards,
  Tony
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] Kill-safe, single-write, blocking box (was Re: scheme_sema_post_all)

2011-10-22 Thread Matthew Flatt
I think you could get this behavior by creating a manager thread when
you create the new kind of box. If threads are too heavyweight, though,
you can get the effect of a primitive by using `ffi/unsafe/atomic'.

At Sat, 22 Oct 2011 10:24:27 -0400, Tony Garnock-Jones wrote:
> 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


[racket-dev] Kill-safe, single-write, blocking box (was Re: scheme_sema_post_all)

2011-10-22 Thread Tony Garnock-Jones
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