guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about an error with ports


From: Olivier Dion
Subject: Re: Question about an error with ports
Date: Fri, 11 Mar 2022 09:58:59 -0500

On Fri, 11 Mar 2022, Chris Vine <vine24683579@gmail.com> wrote:
> On Thu, 10 Mar 2022 18:46:34 -0500
> Olivier Dion via General Guile related discussions <guile-user@gnu.org>
> wrote:
>> On Thu, 10 Mar 2022, Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:
>> 
>> > Just one question: Why is get-bytevector-some better than
>> > get-bytevector-n and specifying a number of bytes?
>> 
>> I haven't check the implementation details, but I think it's just a
>> question of buffering.  `get-bytevector-n` will block just like
>> `get-bytevector-some` when the port is empty.  The former will return up
>> to N bytes and the latter might return more than N bytes.  The former
>> probably also lead to less memory allocation since N is known in
>> advanced, a singled allocation can be made, while the latter might do
>> multiple allocations.  This can be useful depending on your usage of the
>> port.  For example, you could make a web server that only accepts HTTP
>> body up to 4096 bytes (1 system page).  This is what some web server
>> does I think.
>> 
>> There's also `get-bytevector-all`, but this would lead to more memory
>> usage and multiple allocations.  Again, it depends on the usage.
>
> Avoid using get-bytevector-n!, get-bytevector-some and
> get-bytevector-all if you are going to use something like fibers or
> some other asynchronous i/o, as those procedures are not suspendable
> (they can block).  get-bytevector-n (note the difference from
> get-bytevector-n!) and get-string-all are suspendable and should
> generally be preferred where suspension is required.

I'm not sure this is related to the functions themself but instead the
underlying filedescriptor opened iwth ON_NONBLOCK?

-- 
Olivier Dion
Polymtl



reply via email to

[Prev in Thread] Current Thread [Next in Thread]