From: gil@max.corp.mot.com (Gil Levendel)
Message-Id: <9603150532.AA09259@palatine>
Subject: pthread library ?'s
To: proven@MIT.EDU
Date: Thu, 14 Mar 1996 23:32:22 -0600 (CST)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit


Hello,

I've been using your pthreads library version 1_60_beta5 and
earlier (thanks for this library!).

I've come across a problem that I cant seem to explain (I'm
running this on an i486 running FreeBSD R2.1):


1) I create a thread which services TCP connection requests.
   The thread creates, binds, listens, etc.  Immediately after
   the thread does a blocking call to accept(), fstat returns the
   following information about my application:

gil      app         8100   wd /usr      42372 drwxr-xr-x     512  r
gil      app         8100    0 /          4196 crw--w----   ttyp3 rw
gil      app         8100    1 /          4196 crw--w----   ttyp3 rw
gil      app         8100    2 /          4196 crw--w----   ttyp3 rw
gil      app         8100    3 /           290 -rw-r--r--   59786  r
gil      app         8100    4* internet stream tcp f0860200


    The file descriptor (for the listener socket) returned to the
    application is fd 4. OK. So far so good.


2) Immediately after a connection request is made from a second
   (remote) process, the server thread creates a udp socket and
   a pipe and creates a new thread to handle the new connection.
   At this point fstat returns the following:

gil      app         8100   wd /usr      42372 drwxr-xr-x     512  r
gil      app         8100    0 /          4196 crw--w----   ttyp3 rw
gil      app         8100    1 /          4196 crw--w----   ttyp3 rw
gil      app         8100    2 /          4196 crw--w----   ttyp3 rw
gil      app         8100    3 /           290 -rw-r--r--   59786  r
gil      app         8100    4* internet stream tcp f0860200
gil      app         8100    5* internet stream tcp f0897d00
gil      app         8100    6* internet dgram udp f0936880
gil      app         8100    7* local stream f08c0414 <-> f0852b14
gil      app         8100    8* local stream f0852b14 <-> f08c0414

    The newly created tcp socket is file descriptor 5, and a newly
    created udp socket is file descriptor 6. There has also been
    a pipe created at fd's 7 and 8.

    The problems:

    1) The file descriptors returned to the application are 6, 7, 8
       and 9, respectively, instead of 5, 6, 7, 8.

    2) A subsequent call to select by the new thread (readset =
       6, 7, 8) blocks correctly. When I hit the enter key, the select
       unblocks, returning a value of 7 because fd 8 has data available.
       Apparently fd 8 is somehow associated with stdin?


That's basically it. I've made sure that compilation is done
correctly. I dont see any contention issues. Any ideas as to what
may be going on? If more information is needed, let me know.


Thanks in advance,
Gil Levendel