fibers on a unix socket

fibers on a unix socket

[Catonano]

Hello

in Fibers there's an example of a client connecting to a server

I'd like to do the same thing BUT in my case the server provides a unix
socket.

It's a unix socket provided by Postgresql. On Ubuntu it's here
/var/run/postgresql/.s.PGSQL.5432

I'm wondering about these 3 lines the fibers client uses

    ;; Disable Nagle's algorithm.  We buffer ourselves.
    (setsockopt port IPPROTO_TCP TCP_NODELAY 1)
    (fcntl port F_SETFL (logior O_NONBLOCK (fcntl port F_GETFL)))
    (setvbuf port 'block 1024)

Can a unix socket be non blocking ?

Does it make any sense if I set the block size to 1024 ?

Thanks

Re: fibers on a unix socket

[Chris Vine]

On Thu, 31 Jan 2019 17:43:42 +0100
Catonano <catonano@gmail.com> wrote:
> Hello
> 
> in Fibers there's an example of a client connecting to a server
> 
> I'd like to do the same thing BUT in my case the server provides a unix
> socket.
> 
> It's a unix socket provided by Postgresql. On Ubuntu it's here
> /var/run/postgresql/.s.PGSQL.5432
> 
> I'm wondering about these 3 lines the fibers client uses
> 
>     ;; Disable Nagle's algorithm.  We buffer ourselves.
>     (setsockopt port IPPROTO_TCP TCP_NODELAY 1)
>     (fcntl port F_SETFL (logior O_NONBLOCK (fcntl port F_GETFL)))
>     (setvbuf port 'block 1024)
> 
> Can a unix socket be non blocking ?

Yes.  If you are using it with fibers it must be made non-blocking
with the aforementioned application of fcntl.

> Does it make any sense if I set the block size to 1024 ?

Yes.  Sockets are unbuffered by default and the call to setvbuf
substitutes block buffering, which means that (if the port is not
explicitly flushed) output will flush when the buffer becomes full or
when the port is closed, and input will do look-ahead buffering.  The
other options are the default of no buffering (which is OK for output
ports if you are sending largish chunks of data, but not a good idea
for input) or line buffering, whereby a newline flushes the output
buffer and which you might want if you are sending text.

The buffering status of the port has nothing to do with whether the
port's descriptor is set blocking or not.  As I said, for asynchronous
i/o it must be.  The word "block" here is being used in two unconnected
senses.

Re: fibers on a unix socket

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Thu, Jan 31, 2019 at 05:43:42PM +0100, Catonano wrote:
> Hello
> 
> in Fibers there's an example of a client connecting to a server
> 
> I'd like to do the same thing BUT in my case the server provides a unix
> socket.
> 
> It's a unix socket provided by Postgresql. On Ubuntu it's here
> /var/run/postgresql/.s.PGSQL.5432
> 
> I'm wondering about these 3 lines the fibers client uses
> 
>     ;; Disable Nagle's algorithm.  We buffer ourselves.
>     (setsockopt port IPPROTO_TCP TCP_NODELAY 1)

The one above probably doesn't make sense for Unix domain sockets
(it is specific to IP sockets and it is meant to delay sending
a small packet in the hope that more stuff arrives, to avoid lots
of tiny packets)

>     (fcntl port F_SETFL (logior O_NONBLOCK (fcntl port F_GETFL)))

while this one does make sense (as Chris notes): you want your other
fibres to do their happy dancing instead of blocking the whole process
in the read.

>     (setvbuf port 'block 1024)
> 
> Can a unix socket be non blocking ?

Yes, they can be both. In this respect they are not different from
IP sockets.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]