Tue, Jun 26, 2001 at 11:11:21PM +0200, Shane Kerr:
> On 2001-06-26 13:43:46 -0700, Archie Cobbs wrote:
> > Takashi Ishihara wrote:
> > > > I think pth_read() will normally block unless you use pth_fdmode()
> > > > to set the descriptor to non-blocking.
> > >
> > > This is not true after Pth 1.1.
> > > Read pth man(1) utilities section.
> > > In ps version, it's near the end of p.11.
> > > It says "pth_read(3) or pth_write(3) will never block the current thread".
> >
> > You forgot the beginning of that sentence: "Instead when you now
> > switch a file descriptor explicitly into non-blocking mode, ...".
> >
> > I read this to mean that if you don't switch it into non-blocking
> > mode, then it will block.
>
> That's my interpretation. So basically pth_read() and pth_write() work
> the same as read() and write() - exactly what you'd expect. Trust me,
> pth_read() and pth_write() do block when you have the file descriptor
> set to delay.
the behavior i have seen indicates that _fdmode is equivalent to fcntl().
i had set the FD non-blocking with fcntl(). __pthread_{poll,read,write}
were blocking and afaik there is no __pthread_fdmode() requivalent, but
one should be able to use fcntl(), unless i've missed something within or
misunderstood the manual for pthread.
it appears that my problem of pth_{poll,read,write} blocking was induced
by trying to use pth_* mixed in with pthread stuff. eg: i had not done
pth_init(). i have no other explaination. for after i had converted all
the pthread remnants to pth_, it began working as expected. appologies
for any wasted time.
i still have no idea why the __pthread versions blocked.
of course, use of pth means i dont get some of the solaris native pthreads
code for "free". :(
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
