nonblocking option for net-accept?

[TedWalther]

Lutz, can we have a non-blocking option for a listening socket, so I can accept and also handle socket session without doing a spawn/sync dance?  I think net-select and net-peek already let me do what is needed to multiplex multiple connections in one process, just need a non-blocking net-accept.

[TedWalther]

The use case for this is I want to accept connections and keep them alive and process them in a round robin way while still accepting new connections.  Otherwise it gets annoying trying to let all the different incoming connections interact with each other and a common shared state.

[TedWalther]

I did look at prodcons.lsp in the examples directory, and it doesn't look like it can do the job, because the server won't know the semaphore value for the individual connections that come in, assuming I fork for each connection and copied the producer/consumer code.

[Lutz]

try to work with net-listen:



http://www.newlisp.org/downloads/newlisp_manual.html#net-listen">http://www.newlisp.org/downloads/newlis ... net-listen">http://www.newlisp.org/downloads/newlisp_manual.html#net-listen

[TedWalther]

try to work with net-listen:



http://www.newlisp.org/downloads/newlisp_manual.html#net-listen">http://www.newlisp.org/downloads/newlis ... net-listen">http://www.newlisp.org/downloads/newlisp_manual.html#net-listen

Lutz, I read through that.  Did I miss something?



My use case is:

Code Select Expand


;; pseudocode
(net-listen port "nonblocking")
(set 'active-connections (list))

;; event loop
(while true
  (set 'newclient (net-accept)) ;; non-blocking
  (if newclient (push newclient active-connections))
  (do-something-with (net-select active-connections))
  (close-and-remove-inactive-connections)
)


I want to have multiple persistent connections in the server, but without them being blocked waiting for a new connection.  I don't know a way to net-peek for a new and incoming connection to accept, so allowing the non-blocking option seems the easiest way.  And return nil if there is no incoming connection to return.

[Lutz]

Why does net-select not work for you? Maybe I don't understand the question.

[TedWalther]

Why does net-select not work for you? Maybe I don't understand the question.

One learns something new every day.  Thank you Lutz.



Whether for straight read, or for accept, without setting nonblocking mode on the socket, select() isn't guaranteed to give you back a socket that will return a result right away, it can still block.



I just did a search about using select to do a non-blocking accept, and found this on stack overflow:

Hmm, that's a well-known race condition - the accept(2) will block if client drops connection attempt between two syscalls. You need the listening socket to be non-blocking. – Nikolai Fetissov Aug 10 '10 at 0:35



This is correct - you can add your listening file descriptor to the readfds in your select() call, and select() will tell you the file descriptor is "readable" if it has a connection ready to accept(). @Nikolai is correct too - the listening socket should be nonblocking and the accept() call prepared to handle EAGAIN. – caf Aug 10 '10 at 0:35

Needs to handle EAGAIN and also EWOULDBLOCK as the potential errno.



So it would still be good to be able to set O_NONBLOCK on a socket at the net-listen stage.

[TedWalther]

Another quote, from here: https://jameshfisher.com/2017/04/05/set_socket_nonblocking.html">https://jameshfisher.com/2017/04/05/set ... cking.html">https://jameshfisher.com/2017/04/05/set_socket_nonblocking.html

If our server only makes calls which select has indicated will not block, will everything be OK? No! These two operations - select followed by the hopefully non-blocking call - are non-atomic. By the time the server makes the call, the situation may have changed! A pending connection may disappear before we try to accept it. A client attempting to send data may disappear before we try to read its data. Data may be read from a socket by a different process before we get to it.