OSDev.org

I just wonder: is the accept() system call blocking per se or should there any option to have it return to the program with an error code?

Hi,

beyond infinity wrote:I just wonder: is the accept() system call blocking per se or should there any option to have it return to the program with an error code?

AFAIK (and I'm no expert), the accept() function never blocks, and never needs to.

Typically the server uses listen() on a control socket to wait for a new connection, and only uses accept() after a new connection is requested. The accept() function just creates a second socket for the new connection while leaving the control socket unchanged.

The listen() function would block though (and IMHO should have an option to have it return to the program with an error code, but IIRC doesn't).


Cheers,

Brendan

so if I understand correctly, listen makes the process/thread block on the socket (and eventually binds the socket to a local address if this has not happened before via bind()).

Upon accept, the network stack merely pries the first element of the accept_queue (this one is stored in the tcp Protocol control block assigned to that socket f. ex.) - which is by itself a protocol control block, returns this one to the socket layer which stuffs it in the generic socket data struct - and returns a socket id to the caller.

The connection itself is only then setup completedly, when the thread/process sends its very first chunk of data (last piece of tcp three way handshake)

hm ... I need to wrap more brain around this. Thanks!

if you need a comprehensive overview of how socket operations really work, i strongly suggest you "Beej Guide to network programming".

Afaik (and i'm supposed to be an expert ) the "listen" syscall simply tells the OS that connections can be received on a given port and that they're to be directed to a given socket. The "listen" syscall is therefore not blocking in any way (i mean, there's nothing to wait for)

The "accept" syscall, on the other side, tells the system to wait for an incoming connection on the given socket. If there's a connection there, fine, it will not be blocking. If there isn't, "accept()" will actually wait until a connection request arise.

(btw, this thread would probably better suit the "general programming" board)

beyond infinity wrote: I just wonder: is the accept() system call blocking per se or should there any option to have it return to the program with an error code?

Now, you _can_ make the accept() call non-blocking by changing the appropriate socket option (see your manpage for setsockopt) so that it returns EWOULDBLOCK or EAGAIN if no connection is immediately available. You can then poll() or select() the socket descriptor until there's "something to read" on it, which tells you there is now a connection you can accept.

*grr*movingmythreadsaroundgrml*

It *might* occur to the reader, that I'm asking this because I'm in the planning stage of a TCP/IP stack for my Operating system? Ok, Sorry, should have added this beforehand.

I own several books on tcp/ip and the innards of its implementation.

I'm asking about small details which I haven't understood yet, ok?

Btw, thanks for elucidation again! I'm still thinking it over and doing some sketches on paper.

beyond infinity wrote: *grr*movingmythreadsaroundgrml*

It *might* occur to the reader, that I'm asking this because I'm in the planning stage of a TCP/IP stack for my Operating system? Ok, Sorry, should have added this beforehand.

I own several books on tcp/ip and the innards of its implementation.

I'm asking about small details which I haven't understood yet, ok?

Btw, thanks for elucidation again! I'm still thinking it over and doing some sketches on paper.

afaik it's just like read. It blocks if there's nothing to do, it returns if it can fulfill the request. It doesn't block in nonblocking and returns either the proper answer or EAGAIN or EWOULDBLOCK as Pype has said.

You could make a default mechanism that didn't work like socket ++ listen, but more like openListenSocket(ip, port, function_to_be_called_with_new_sockets) which would make multithreading programs a lot easier and more common... For all programs but big multiuserservers this approach works better than single-threaded. Say, anything at the hobby-OS level... It also allows you to not just create a thread but use multithreading method XYZ, such as worker threads etc.