On Thu, 2007-04-19 at 00:23 +1000, skaller wrote: > On Wed, 2007-04-18 at 23:53 +1000, skaller wrote: > > Release 1.1.3 is currently being held up by a problem > > with the webserver.
I just looked and faio is performing properly. Exactly the right data is read in (I dumped it and it terminates right after </HTML> like it should). There's no reason to assume writing to the socket is wrong: the actually failure is 64K or SIX whole buffer loads earlier. There's only one logical explanation left. The operating system has a 64K buffer for socket output, and when it is filled by the webserver, the webserver shuts down the socket, and this just loses the buffers. I'd rate that as a bug in Linux: close/shutdown should finish dumping the buffers. Checking the POSIX specs: http://www.opengroup.org/onlinepubs/009695399/functions/close.html it appears that the problem must be: 1) The socket is in non-blocking mode 2) SO_LINGER is not set. "If fildes refers to a socket, close() shall cause the socket to be destroyed. If the socket is in connection-mode, and the SO_LINGER option is set for the socket with non-zero linger time, and the socket has untransmitted data, then close() shall block for up to the current linger interval until all data is transmitted." "If a STREAMS-based fildes is closed and the calling process was previously registered to receive a SIGPOLL signal for events associated with that STREAM, the calling process shall be unregistered for events associated with the STREAM. The last close() for a STREAM shall cause the STREAM associated with fildes to be dismantled. If O_NONBLOCK is not set and there have been no signals posted for the STREAM, and if there is data on the module's write queue, close() shall wait for an unspecified time (for each module and driver) for any output to drain before dismantling the STREAM. The time delay can be changed via an I_SETCLTIME ioctl() request. If the O_NONBLOCK flag is set, or if there are any pending signals, close() shall not wait for output to drain, and shall dismantle the STREAM immediately." I have no idea at the moment if a socket is a STREAM. However this would suggest if O_NONBLOCK is set for the socket, it would explain the problem. Now the thing is the blocking status of the socket is indeterminate: the socket was created from a listener, and POSIX doesn't say what attributes it has. My man page: On Linux, the new socket returned by accept() does not inherit file status flags such as O_NONBLOCK and O_ASYNC from the lis‐ tening socket. This behaviour differs from the canonical BSD sockets implementation. Portable programs should not rely on inheritance or non-inheritance of file status flags and always explicitly set all required flags on the socket returned from accept(). It looks like we'd better set the required flags. This is all I can think of to solve the problem. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
