In working on some prototypes for a threaded DBMail, I've been reading up on ways to handle timeouts. What we do now is set an alarm(2) then call a blocking I/O function like fread, and if we don't get the data we want in that time period, the system call is interrupted by the delivery of SIGALRM and we close up the connection and log the timeout.
In a threaded system, we cannot call for an alarm, because it could be delivered to any thread and not just the calling thread -- and this varies by platform, according to all the docs out there. One option is to have a timing thread, and before each read, send a message to the timing thread with a timeout and thread id, begin the read, and when the read is over, send a message to cancel the timer. If the timing thread times out, it sends a pthread_cancel to the reading thread, which will interrupt the read syscalls. Another option is to use non-blocking IO and maintain the timeout as part of a select() / poll() loop around the data to be read. If the select timer ever runs out before finding the socket ready for reading, then we've gone on too long as we close up the connection. Any favorite practices out there before I get too far into one method or the other? Aaron _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
