Re: name for singlethreaded web server framework module (chatty)
On Sat, Aug 21, 2004 at 06:52:27PM -0500, david nicol wrote: Better to be a team player and release HTTP::Server::Singlethreaded which would invoke the correct class of considerations for those whose initial referent for Selecting is not the Berkeley socket library. Seems sensible enough (and I read that you've uploaded under that name) Does Perl have non-blocking file IO yet? I know Uri Guttman requested non-blocking file IO some time ago. I've thought about serving larger static files with open my $OutBound, cat $filename|; and incorporating these pipes into the multiplexion, but this approach (1) is not portable to places where cat(1) is not installed and (2) requires more complex multiplexion than is needed for The Task At Hand and is therefore deferred according to the best practices of Extreme Programming. Presumably generating pipes to helper tasks can be done with a module on CPAN? And is it really going to achieve faster non-blocking file IO on anything other than Unix (or Unix-a-likes) where there will be cat? Nicholas Clark
move to RT: Re: name for singlethreaded web server framework module (chatty)
this discussion is getting into the details -- i guess I could make a page for singlethreaded on Perlforge if it existed, or we could move the discussion to rt, for instance https://rt.cpan.org/Ticket/Display.html?id=7446 IMO it would be nice if RT provided an announce mailing list for each queue. It might have something like that already, with the possiblity of receiving reports for new tickets created in queues you have signed up for. On Mon, 2004-08-23 at 11:33, Nicholas Clark wrote: Presumably generating pipes to helper tasks can be done with a module on CPAN? And is it really going to achieve faster non-blocking file IO on anything other than Unix (or Unix-a-likes) where there will be cat? Nicholas Clark version 0.03 now does partial reads on large files, keeping the handles in a per-client array for reading from when the outbuffer for that client gets small. I guess version 0.04 will extend this to programs which will get opened into pipes, and do selects on the handles to avoid blocking, since nonblocking is not portable. -- david nicol Someday, everything's going to be different when I paint my masterpiece.
Re: name for singlethreaded web server framework module (chatty)
Version 0.01 buffers the generated data (including slurped files) and does not provide a standard CGI execution environment. I could just brand it. Web server names are pretty opaque, at least Apache and Boa are. When it's done (hopefully today, this is for a project due yesterday) I could put it on CPAN as TipJar::webserver although that's misleading too -- nobody uses TipJar::fields as far as I can tell. (And nobody uses tipjar.com because it's down.) Maybe I should rerelease TipJar::fields as something else, although David M. Lloyd's enum::fields is arguably better and predates it. Enough of this digression. Better to be a team player and release HTTP::Server::Singlethreaded which would invoke the correct class of considerations for those whose initial referent for Selecting is not the Berkeley socket library. Does Perl have non-blocking file IO yet? I know Uri Guttman requested non-blocking file IO some time ago. I've thought about serving larger static files with open my $OutBound, cat $filename|; and incorporating these pipes into the multiplexion, but this approach (1) is not portable to places where cat(1) is not installed and (2) requires more complex multiplexion than is needed for The Task At Hand and is therefore deferred according to the best practices of Extreme Programming. On Sat, 2004-08-21 at 13:52, Randy W. Sims wrote: I'm not sure how descriptive Selecting is. Maybe HTTP::Server::Simple or HTTP::Server::Synchronous ? On Sat, 2004-08-21 at 14:01, Nicholas Clark wrote: I infer from the description that it's going to serve files representing parallel requests by multiplexing using select(). Will it just serve static content, or also dynamic generated content from user code? If so, how do you feed that out via select? - non-blocking API, or just buffer the generated DATA in memory and then feed it out at the pace dictated by select() and non-blocking IO? because I'm not convinced that this name would give much insight into the implications of the implementation, and the trade offs they give. -- david nicol Someday, everything's going to be different when I paint my masterpiece.
