You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2002/12/29 09:38:03 UTC
Re: [mp2] APR::Socket::recv set read timeout ?
Doug, Michael asks how to poll on Apache::Socket in the protocol
handlers. It seems that APR::Poll's functions should do the work, but
it's !APR::Poll in the map file. Any reason for not having this module
enabled?
Would be nice to annotate the map files to explain why certain modules
aren't glued, to avoid drags in the future.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] APR::Socket::recv set read timeout ?
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 31 Dec 2002, Stas Bekman wrote:
> Do you have a pointer to the thread you are talking about?
no, but there are several. the thread on removal of client_socket from
conn_rec likely has some good details.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] APR::Socket::recv set read timeout ?
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Mon, 30 Dec 2002, Stas Bekman wrote:
>
>
>>Do you have an example of such a protocol handler, which uses bbs?
>
>
> no, but using filters would be the proper way. we really shouldn't even
> be exposing $r->connection->client_socket based on discussions i've seen
> on dev@httpd. we need to make connection filters easier to use in
> Perl land (the stream like interface), not expose methods to use
> client_socket directly.
Do you have a pointer to the thread you are talking about?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] APR::Socket::recv set read timeout ?
Posted by Doug MacEachern <do...@covalent.net>.
On Mon, 30 Dec 2002, Stas Bekman wrote:
> Do you have an example of such a protocol handler, which uses bbs?
no, but using filters would be the proper way. we really shouldn't even
be exposing $r->connection->client_socket based on discussions i've seen
on dev@httpd. we need to make connection filters easier to use in
Perl land (the stream like interface), not expose methods to use
client_socket directly.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] APR::Socket::recv set read timeout ?
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Mon, 30 Dec 2002, Stas Bekman wrote:
>
>
>>Yes, when protocol handlers are working directly with a connection
>>socket, filters can't be used.
>
>
> why the need to use the connection socket directly rather than via
> filters?
Because to use filters you need to work with bucket brigades, which
makes it much harder to implement interactive protocols, like in your
CommandServer example:
http://www.apache.org/~dougm/modperl_2.0.html#apache::commandserver
Do you have an example of such a protocol handler, which uses bbs?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] APR::Socket::recv set read timeout ?
Posted by Doug MacEachern <do...@covalent.net>.
On Mon, 30 Dec 2002, Stas Bekman wrote:
> Yes, when protocol handlers are working directly with a connection
> socket, filters can't be used.
why the need to use the connection socket directly rather than via
filters?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] APR::Socket::recv set read timeout ?
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> if you asked how to implement the same module in C on dev@httpd, they'd
> say "use filters". which handles timeout, buffering, putback, etc.
> pretty sure that's the right answer here too.
> are there some good reasons not to use filters here?
Yes, when protocol handlers are working directly with a connection
socket, filters can't be used.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] APR::Socket::recv set read timeout ?
Posted by Doug MacEachern <do...@covalent.net>.
if you asked how to implement the same module in C on dev@httpd, they'd
say "use filters". which handles timeout, buffering, putback, etc.
pretty sure that's the right answer here too.
are there some good reasons not to use filters here?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org