From: David Wragg <dpw93@ecs.soton.ac.uk>
Message-Id: <12286.9512050843@vermeer.ecs.soton.ac.uk>
Subject: Misc. bugs
To: pthreads-bugs@MIT.EDU
Date: Tue, 5 Dec 1995 08:43:55 +0000 (GMT)
Content-Type: text
Content-Length: 2838      

Hi,

I've been using your PThreads implementation (version 1.60, beta 4)
and I have noticed a few problems with it. The first 4 have simple
fixes, 5 is a more general query.

1.

The declarations for many of the socket calls are missing from the
socket.h files for many architectures.

2.

The dup2 function can't handle the two fds passed being equal. I think
most POSIX OSes detect this and do nothing.

3.

When the "-E" option to preprocess is used with the pgcc and pg++
scripts, they still put the linking options on the gcc command line.

4.

There are a couple of bugs in the file net/gethostbyname.c, which I
discovered on a Linux machine with no network connection except the
loopback interface. Neither of them is specific to PThreads, I think.

Around line 101 in gethostname.c, the /etc/hosts file is queried if a
connection to the name server is refused (errno ==
ECONNREFUSED). However, as this machine had no name server to contact
it failed with errno == ETIMEDOUT, and didn't look in the /etc/hosts
file. Since it was looking for the host "loopback" it would certainly
have found itself had it looked. I would suggest that if attempting to
resolve via the name server fails, the hosts file should be searched
under a much wider variety of circumstances (the GNU C libs do under
any circumstances).

The other bug occurs when searching the hosts file in line 147. In

			if (strcasecmp(alias, name) == 0)

alias is a char **, and the result is that aliases never match (this
machine also had its hostname as an alias for "loopback"). It should
be:

			if (strcasecmp(*alias, name) == 0)

5.

I find the way PThread handles signals slightly strange. As I
understand it, if a waiting thread recieves a signal, that signal
pends until the thread runs, and then the signal handler is invoked.

This means that, for example, if the main thread is the only thread
that will signals unblocked, and it sleeps, then no signals (such as
SIGINTs from ctrl-C) will get handled untill it awakes.

The behaviour I would have expected is that if a signal occurs, and
only a waiting thread can take it, then the waiting thread should
become runnable, and the PThreads call it waited inside should return
EINTR.

This would be useful in other ways. If there is a thread using
select() to wait for data on a number of fds, and it becomes necessary
for it to wait on another fd, the thread could be signaled, the
select() would interrupt, and the thread could pick up the request to
wait on another fd. As it stands, the only way I can see to do
something like this is to use the select() with a pipe down which
dummy data is sent.

If PThreads works the way the Posix Threads standard documents define
then fair enough, but it would be nice to have the option.


Could you send back some sort of acknowledgement?
Many thanks,
Dave Wragg.