[329] in Pthreads mailing list archive
bugs/fixes/subscription
daemon@ATHENA.MIT.EDU (Josh Littlefield)
Wed Jun 5 17:09:19 1996
To: pthreads@MIT.EDU, pthreads-bugs@MIT.EDU
Date: Wed, 05 Jun 1996 16:26:07 -0400
From: Josh Littlefield <josh@american.com>
Resent-To: pthreads@MIT.EDU
Resent-From: Josh Littlefield <josh@american.com>
I've sent Chris Provenzano a few pieces of mail over the last 2 months which
haven't generated any response -- I may well be using an old address -- so I
figured I'd try the list directly.
We've been using Chris's pthreads 1.60beta5 for internal development and have
found a few bugs and made a few fixes. We'd like to get these out to people,
but felt the best approach was to submit to Chris, the path we've followed so
far. Having gotten no feedback on that, though, we decided to ask if others
on the list had any of the same issues.
- One bug was in fd_init() which only inits one "lump" of the fd_table (where
a lump is 4096/(sizeof (struct fd_table_entry)), while nothing limits
references (fd_table[i]) to this lump.
- Another series of bugs surround select(). Some are simple bugs, some issues
won't be noticed unless you have multiple threads doing selects. But if you
do, they're significant problems.
- There are bugs in gethostbyaddr and gethostbyname (beyond the ones I saw in
the mailing list archives).
- A bug in vfprintf() fails to free an fd lock.
Regarding select(), we seem to have hit a number of questions/issues
concerning its correct behavior. I can't find a good definition for how
select should behave across threads, but the current orientation of select
doesn't seem to match the Solaris implementation (one data point of arguable
significance).
One issue involves multiple threads selecting on the same fd. MIT-pthreads
will serialize them, since each thread wants to exclusively lock the fds it
will select on, thereby stalling any other thread whose fd set intersects with
it. Certainly UNIX doesn't behave this way for multiple processes, and it
seems multple threads should not get in each other's way either.
I suppose many people doing multi-threading don't feel the need for using
select, but we have a work-generation model for threads which really thrives
on focusing delegation of work to a few threads. Multiple threads can end up
in select() to avoid having to always wake one thread from its select to alter
the current fd set.
If anyone has thoughts on these issues, or is Chris is reading this and is
interested in the bugs/fixes, let me know. I'm haven't managed to get on the
mailing list yet, so direct replies are required.
Thanks.
-josh
========================================================================
Josh Littlefield American Internet Corporation
josh@american.com 4 Preston Court
tel: 617-271-9200 fax: 617-275-4930 Bedford, MA 01730-2334
