Takashi Ishihara wrote:
> > In other words, if you're going to set your fd's to non-blocking and
> > use pth_select() and pth_poll(), why are you bothering to use threads
> > in the first place? One great advantage of threading is so you don't
> > have to do that.
>
> Exactly. I worried about messing up my src. It's fairly clean for now,
> but I'm sure it'll be messier after putting pth_select for each I/O operation.
> I'm writing a web server using pth; main goal is 1. good performance (as good
> as Boa) 2. better/cleaner coding (Boa mess around select, so the src is not
> pretty IMHO). If read from network port is set to non-blocking, using
> pth_select would be the reasonable way to work around -1 (EWOULDBLOCK).
> but if pth really multiplexes I/O automatically (even with blocking mode),
> the it's really great. Please verify this. thans.
Yes..
If you never call pth_fdmode() then things work like they "should",
i.e., when a thread calls pth_read() it will block but other threads
will continue to run.
Re-read the man page describing pth_fdmode() -- basically it acomplishes
the *per-thread* equivalent of what fcntl(fd, F_SETFL, O_NONBLOCK) does
for the whole process. This is the newer behavior:
Keep in mind that
since Pth 1.1 there is no longer a requirement to man-
ually switch a file descriptor into non-blocking mode
in order to use it. This is automatically done tem-
porarily inside Pth. Instead when you now switch a
file descriptor explicitly into non-blocking mode,
pth_read(3) or pth_write(3) will never block the cur-
rent thread.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
