On Sun, Jul 13, 2003, Damon Hastings wrote:
> [...]
> > See the file test_common.c in the Pth source tree. It provides a
> > pth_readline() function (just a small but sufficient buffered wrapper
> > around pth_read()) which should do exactly what you want.
>
> It looks like pth_readline_ev() reads a fixed number of bytes at a time
> (i.e. 1024) and will block until it reads that many (or eof). Is that
> right? That works great for reading a file, where more bytes (or eof) are
> always available, but I'm reading from a socket. I was considering a
> non-blocking approach like:
>
> pth_fdmode(fd, PTH_FDMODE_NONBLOCK);
> while (newline not read yet) {
> pth_select on fd readable, with long timeout;
> bytes = pth_read(fd, buff, 1024);
> if (bytes == 0)
> cleanup on closed connection
> }
I'm not sure whether I correctly understand your concerns. Yes,
pth_readline_ev() blocks, but just the current thread, of course.
That's what you usually want in a threaded application: you logically
program each thread in blocking mode, but the threading implementation
takes care that in case a thread would block, another (ready for next
operation) thread is scheduled for execution in the meantime. Internally
Pth uses non-blocking I/O to achieve all this, of course.
If you pth_select() in each thread you don't take advantage of the event
scheduling inside Pth. pth_select() is for if 1 thread wants to poll
many filedescriptors, but not if 1 thread polls for 1 filedescriptor.
Then you just use pth_read(). And the timeout you achieve by using
pth_read_ev() instead of passing it a timeout event. Same for the
wrappers pth_readline() and pth_readline_ev().
> Is there a more efficient approach than this? And should I put a sleep in
> that loop, or will the scheduler automatically handle everything? (I'll
> have about 150 threads in this loop simultaneously, each reading from its
> own socket, with each socket delivering about 1 line of input per second.)
You don't need an explicit sleep there, because Pth's event manager
will automatically suspend your thread and schedule others if an I/O
operation would block. But keep in mind that this is only true if you
use pth_xxx() functions. If you use read(2), sleep(3), etc. directly,
Pth has to chance to perform context switches between the threads. You
have to give Pth a chance to do this by always going through the Pth
API. That's the price for true portability and non-preemtive scheduling.
But usually that's just a matter of programming discipline... ;-)
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
Development Site http://www.ossp.org/pkg/lib/pth/
Distribution Files ftp://ftp.gnu.org/gnu/pth/
Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
