--- "Ralf S. Engelschall" <[EMAIL PROTECTED]> wrote:
> 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.
Yeah, I guess my explanation was a little spotty. :-> What I want is for a
thread to block only until a newline is received on the socket it's reading
from. Suppose the socket receives the 12 bytes "hello world\n". That has a
newline and so I would want pth_readline() to return immediately with the
output "hello world\n". But if pth_readline() does a blocking 1024-byte
read on the socket, it will find only 12 bytes available and will thus
block. Furthermore, the remote host will not send any more bytes because
it's waiting for us to respond, and so pth_readline() will time out, or
never return.
> Sure, Pth just swaps the stack pointer, of course. Nevertheless what
> here was mentioned is the fact that each stack consumes memory. If you
> have a large number of threads in your system, just the allocated stacks
> already accumulate to a rather large memory consumption.
Hey, that's great! I was a little concerned for a moment there. But with
it just swapping a few pointers each context switch, Pth should be much
faster than Linux Pthreads. (And I have 1GB physical RAM, so no worries
about memory consumption.) Can you give me a ballpark idea of the cost per
context switch for 150 threads, almost all of which are waiting on I/O at
any given time? And does Pth block the entire process when all its threads
are blocked? (I would assume so, if you're using a global "select" under
the covers.)
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.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]
