Glenn Strauss wrote:
On Wed, Aug 18, 2004 at 02:09:53PM -0700, Stas Bekman wrote:

Glenn Strauss wrote:

On Wed, Aug 18, 2004 at 12:59:51PM -0700, Ken Simpson wrote:


the APR::Socket object is an opaque one, so it can't interoperate with any other perl modules. Have you looked if there is some C api to get the native socket object? There could be one (as they have for file objects), I didn't check.

I looked through apr_network_io.h, which seemed like the logical place, and couldn't find an API that returns the native socket object. But I'm pretty unfamiliar with the Apache code base, so someone else would probably have better luck.


This is what we'd need bound to the Perl API:

apr_os_sock_t fd;
apr_os_sock_get((apr_os_sock_t *) &fd, (apr_socket_t *) client_socket);

On Unix-type platforms, apr_os_sock_t is an int -- the file descriptor,
which you can use with select() or IO::Select() or anything you
like in Perl to poll the descriptor:

and what do you do with socket fd to get it to work with IO::Select?


Perl's equivalent of fdopen():
  open($FH, "<&=$fd")
and then use $FH

I guess that could work.

but I'm not sure how could we write a perl glue for apr_os_sock_get. How will you handle apr_os_sock_t? You can't force it into int, can you?

$rin = '';
vec($rin, $fd) = 1; ## $fd directly instead of fileno(STDIN) or fileno($FH)
...
$nfound = select($rout=$rin, undef, undef, $timeout);



(On other platforms, like Windows, I don't know what apr_os_sock_t is; check the headers files. :)

I'd rather not expose OS specific bits if they won't work with all perl modules. APR provides the API that should (hopefully) work on all platforms, so why not use that?


I'm not a Windows programmer, but in the case of sockets, it looks like
it might be an int (file descriptor) on Windows, too.  We're talking
Berkeley sockets on both platforms, right?  Whatever socket() returns.

why then APR went through the pain of abstracting this interface?

While, you're right that this is better hidden by APR, don't let
cross-platform concerns entirely prevent you from getting the job done. :)

no objections here. But as I understood Ken is working on a common module, which should work everywhere.


--
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html



Reply via email to