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