From: Alex Rousskov Date: Fri, 12 Sep 2008 02:58:44 +0000 (-0600) Subject: Cleaned up Comm: comm_close, comm_read_cancel, half-closed monitors, leaks. X-Git-Tag: SQUID_3_1_0_1~49^2~46^2~1 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=02fc4b6f0741fc8be54584f0755bf7f155dc2301;p=thirdparty%2Fsquid.git Cleaned up Comm: comm_close, comm_read_cancel, half-closed monitors, leaks. 1) Comm_close now implements the following API: Comm_close does not close the descriptor but initiates the following closing sequence: 1) The descriptor is placed in a "closing" state. 2) The registered read, write, and accept callbacks (if any) are scheduled (in an unspecified order). 3) The close callbacks are scheduled (in an unspecified order). 4) A call to the internal descriptor closing handler is scheduled. Details of the above steps are being documented separately and will become a part of Comm API documentation. Since all notifications are asynchronous, it is possible for a read or write notification that was scheduled before comm_close was called to arrive at its destination after comm_close was called. Such notification will arrive with COMM_ERR_CLOSING flag even though that flag was not set at the time of the I/O (and the I/O may have been successful). CommIoCbParams::syncWithComm is used for this. The credit for this trick goes to Christos Tsantilas. Removed fde.flags.closing_ flag as unused. 2) Removed most of the half-closed monitoring code. Old code scheduled monitoring reads every main loop iteration, I think. It is possible that the assumption was that the handler will be activated and cleared once per iteration so that the new read can be scheduled. The design could result in conflicts between two monitoring reads and possibly between a monitoring read and an active read. There were also problems with handling closing descriptors. I have removed the loop, AbortChecker, and the associated splay tree). When user code marks the descriptor as half-closed, Comm now simply schedules a monitoring read callback. If the user needs to check whether the descriptor was marked, Comm checks whether the callback is present. If a user schedules a read when there is already a monitoring callback, the monitoring callback is removed. Renamed user-facing monitoring functions but left compatibility wrappers in place to minimize user code changes, for now. It is possible that the whole half-closed monitoring code will be eventually deleted. The above changes are meant to preserve the intended functionality (but without coredumps) while the decision is being made. 3) Removed _SQUID_LINUX_-only code that would avoid addrinfo destruction on connect "errors". Squid seems to be working fine without this code. With this code, we leak memory on many connect requests because of EINPROGRESS. More work is probably needed to reproduce and fix the true cause of the memory corruption observed earlier. Removing the workaround will allow us to get more bug reports if the problem is still there. --- 02fc4b6f0741fc8be54584f0755bf7f155dc2301