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]