[gambit-list] Question on "buffering:" option for vector-port

Meng Zhang wsxiaoys.lh at gmail.com
Tue Jan 24 22:56:00 EST 2012


I used to think the "write" will block till the consumer thread "read" the
same port under "buffering: #f". (which simulates golang's channel)

Now I can kind of understand that the "buffering" here refer to the "write"
to port,rather than "write" to "consumers".


On Wed, Jan 25, 2012 at 11:15 AM, Marc Feeley <feeley at iro.umontreal.ca>wrote:

>
> On 2012-01-22, at 12:09 PM, Meng Zhang wrote:
>
> > I expect the reading option may block the thread with "buffering: #f".
> >
> > For example:
> > (let ((chan (open-vector '(buffering: #f))))
> >   (thread-start!
> >     (make-thread
> >       (lambda ()
> >         (write "Value" chan)
> >         (pp "Write done"))))
> >   (thread-start!
> >     (make-thread
> >       (lambda ()
> >         (thread-sleep! 1)
> >         (pp "Start reading")
> >         (pp (read chan)))))
> >   (thread-sleep! 5))
> >
> > My expectation:
> > Outputs:
> > "Start reading"
> > "Write done" or "Value", in any order.
> >
> > Result for 4.6.3, osx 10.6.7:
> > Outputs:
> > "Write done"
> > "Start reading"
> > "Value"
> >
> > Obviously, the "read" option doesn't block the spawned thread even
> "buffering" is set to #f.
> > Did I misunderstand it?
> >
>
> When you set buffering to #t, you are telling the runtime system that it
> is allowed to buffer the data that is output.  The runtime system may drain
> the buffers at anytime it wishes.  In other words setting buffering to #f
> guarantees that the data is not buffered, but there are no guarantees when
> buffering is #t.
>
> Here's another example derived from yours:
>
> (let ((chan (open-vector '(buffering: #t))))
>
>  (thread-start!
>    (make-thread
>      (lambda ()
>        (let loop ()
>          (thread-sleep! .2)
>          (write "Value" chan)
>          ;;(force-output chan)
>          (pp "Write done")
>          (loop)))))
>
>  (thread-start!
>    (make-thread
>      (lambda ()
>        (let loop ()
>          (pp "Start reading")
>          (pp (list 'got (read chan)))
>          (loop)))))
>
>  (thread-sleep! 5))
>
> As it is, the second thread will read from the vector port in bursts.
>  What is perhaps surprising is that the second thread starts waiting for
> data to read, then the first thread writes the first data, and the second
> thread immediately reads it.  That's because the first buffer is allocated
> lazily when the first data is written.  On the following writes by the
> first thread, the second thread will wait until the buffer is full.  To get
> synchronous writes and reads, either buffering should be set to #f, or the
> (force-output chan) should be uncommented.
>
> Marc
>
>


-- 
Zhang Meng
School of Software Engineering, Tongji University
MP: +86 151-2103-2798
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20120125/792c8ec3/attachment.htm>


More information about the Gambit-list mailing list