I found the followin problem in the pthread emulation of pth 1.3.7,
but I think it's a generic one and also in plain pth.
The pth was configured with
# ./configure --enable-syscall-soft --enable-pthread
# cat /kern/version
NetBSD 1.3.3 (SHADOWS) #52: Thu Oct 12 11:24:42 EEST 2000
# pthread-config --version
GNU Pth 1.3.7 (29-Jul-2000) [Pthread API]
# cat Makefile
CC = gcc
LD = gcc
CFLAGS = `pthread-config --cflags` -c
LDFLAGS = `pthread-config --ldflags`
LIBS = `pthread-config --libs`
test: test.o
$(LD) $(LDFLAGS) -o test test.o $(LIBS)
test.o: test.c
$(CC) $(CFLAGS) test.c
# cat test.c
#include <stdio.h>
#include <pthread.h>
int
main()
{
fd_set fdset;
int fd = 42; /* the meaning of life, universe and everything */
FD_ZERO(&fdset);
FD_SET(fd, &fdset);
select(fd + 1, &fdset, NULL, NULL, NULL);
return (0);
}
# make
gcc `pthread-config --cflags` -c test.c
gcc `pthread-config --ldflags` -o test test.o `pthread-config --libs`
# ./test
**Pth** SCHEDULER INTERNAL ERROR: no more thread(s) available to schedule!?!?
Abort trap (core dumped)
Why does this happen? Well, in the beginning of the select you put the
only thread to the wait queue, add the fd_set(s) to the set of fds to
be waited and call select(). The select() fails immediately with error
EBADF. This is not handled in any way nor even printed to the debug log.
Then the event handler checks if an error occured and cleans all
fd_set(s). Then all fds are checked and relevant threads are put back to
the runnable queue. Of course now there is none because the fd_sets were
just cleaned. Therefore the handler just exits to the scheduler, which
does not like the fact there's no runnable threads.
Originally this happened to me in a larger program (I had accidently
closed wrong socket). It was quite nasty to try to find the cause
because the error in the select() call does not show even in
the debug version of the library.
Possible fix could be something like sanity checking the fd_sets with zero
timeout select() call before moving the thread to the wait queue?
And BTW, you are not alone. Some other pthreads implementations I have
tried have exactly the same problem.
--
[EMAIL PROTECTED]
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
