Fri, May 23, 2003 at 09:50:02AM -0700, malleswararao venkatanaga:
> Hi,
>  I'm facing a problem and it is somewhat like this,
>   1)I spawn a thread using pthread_create()
>   2) In the thread I open a socket, bind it to a port
> say 10001 and block it in the select call for
> receiving a UDP message.
>   Similarly 
>   In my main thread i open a socket and bind it to a 
> port say 10000 and block the main thread in a select
> call.
>   Both the main thread and the other thread are
> essentially waiting for different messages on
> different ports and different socket fds with their
> respective select calls.
>   I observe that if i send a messages to both of them
> only one of them receives while the other one is still
> blocked in the select call though it has messages to
> read. 
> 
>   Can someone explain me why is this. I might sound
> vague or missing some concept here. But I've tried
> various scenarios but in each of them there are no
> deterministic results most of the cases only one of
> the thread breaks from the select the other one
> doesnot. 
>  I'm using pthreads library which is available in a
> package for the netbsd 1.6 

as I understand the user-space threads model implemented by
packages such as pth, besides being a single process as far
as the kernel is concerned, they are all non-preemptable.
meaning that once a thread begins running, it will either run
to completion (ie: return or pth_exit), until it calls a
function that could block (assuming that function has a
stub/shim in the library that invokes the scheduler, eg: sleep,
read, write), or until the thread explicitly relinguishes the
process (eg: pth_yeild). [someone will probably correct me]

for pth, many of the blocking functions have pth_* equivalents
or the programs can be compiled with an option that causes it's
headers to provide macros that map these calls to the pth_*
versions.  iirc, the netbsd pkgsrc forces this during the build
of pth.  but...see the documentation and src.

i believe that the -current pthreads implementation is also
non-preemptable, but the documentation is a little thin at the
moment and i have not done anything serious with it yet.