internal SITEreader
Russ Allbery
rra at stanford.edu
Sat Feb 1 22:41:44 UTC 2003
Jeffrey M Vinocur <jeff at litech.org> writes:
> The trouble is that by the time the SITEreader message starts getting
> spewed to the logs, it's probably way too late to figure out what caused
> that filedescriptor to be incorrectly marked has readable.
We should probably put some code in RCHANadd that checks to see if
SITEreader is the handler function of the channel being added, and if so,
complains viciously in the logs.
> However, I just stared at the code for a while. Not that I fully
> understand it, but do we need to add the following line?
> void
> RCHANremove(CHANNEL *cp)
> {
> if (FD_ISSET(cp->fd, &RCHANmask)) {
> FD_CLR(cp->fd, &RCHANmask);
> if (cp->fd == CHANlastfd) {
> /* This was the highest descriptor, get a new highest. */
> while (!FD_ISSET(CHANlastfd, &RCHANmask)
> && !FD_ISSET(CHANlastfd, &WCHANmask)
> + && !FD_ISSET(CHANlastfd, &SCHANmask)
> && CHANlastfd > 1)
> CHANlastfd--;
> }
> }
> }
No, because stuff in SCHANmask isn't fed to select. See CHANreadloop.
Those are sleeping channels, which means that we aren't selecting on them.
--
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers
mailing list