[438] in Pthreads mailing list archive
fd_kern_wait & fd_kern_poll
daemon@ATHENA.MIT.EDU (Larry V. Streepy, Jr.)
Mon Sep 30 15:58:08 1996
Date: Mon, 30 Sep 1996 13:47:28 -0600
From: "Larry V. Streepy, Jr." <streepy@healthcare.com>
To: pthreads mailing list <pthreads@MIT.EDU>
Next problem.
I have two threads sitting in select on different fd's. When one of
them gets a connection (these are listen sockets), they both wake up.
In one, the fd sets properly indicate activity on the socket. In the
other thread, the returned count is non-zero, but the fd sets are all
zero.
After some digging into fd_kern.c it seems that the loops that inspect
the results of select can very easily resume threads to don't have any
work to do.
The basic problem is in code which looks like this:
if ((FD_ISSET(i, &pthread->data.select_data->readfds) &&
! FD_ISSET(i, &fd_set_read))) {
FD_CLR(i, &pthread->data.select_data->readfds);
} else {
count_dec++;
}
Note that count_dec is incremented if select_data->readfds is *NOT* set
(regardless of the state of fd_set_read). count_dec being non-zero
causes found_one to be bumped, which causes the thread to be
rescheduled.
Am I missing something brutally obvious here? or is this busted?
I think the code should look like this:
if( (FD_ISSET(i, &pthread->data.select_data->readfds) ) {
if( FD_ISSET(i, &fd_set_read) ) {
count_dec++; /* got a hit */
} else {
FD_CLR(i, &pthread->data.select_data->readfds);
}
}
Feedback?
--
Larry V. Streepy, Jr.
Chief Technical Officer, Healthcare Communications, Inc.
mailto:streepy@healthcare.com
(214) 851-7033 (Dallas Main #)
(970) 626-5028 (My office #) (970) 626-4425 (Fax)
