apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r930533 - /apr/apr/trunk/include/apr_support.h
Date Mon, 12 Apr 2010 15:31:32 GMT
On Mon, Apr 12, 2010 at 9:57 AM, Brian Havard <brian.havard@gmail.com> wrote:
> Jeff Trawick wrote:
>
> On Thu, Apr 8, 2010 at 6:37 AM, Brian Havard <brian.havard@gmail.com> wrote:
>
>
> Brian Havard wrote:
>
>
> Jeff Trawick wrote:
>
>
> [...]
>
>
> For an external API that satisfies this use case, I'd rather see
> something like separate apr_file_wait()/apr_socket_wait() instead of
> the current interface.  (They probably need enums for the I/O type
> too, instead of the int flag.)
>
> This can use wait-for-io-or-timeout internally if appropriate.
>
>
>
> Sounds good. I can start hacking something together if there's agreement.
>
>
>
> Ok, here's what I've come up with.
>
> I haven't done a Win32 implementation because I'm not sure how to wait
> on a file/pipe. I could probably take a stab at doing apr_socket_wait()
> if I get around to digging out a windows compiler but probably best left
> to someone more familiar with apr on windows.
>
> Comments?
>
>
> looks reasonable here
>
>
> After thinking about this a bit more, I'd rather not have apr_file_wait() as
> waiting on regular files isn't portable or even particularly useful. I think
> it would be better to call it apr_file_pipe_wait() to make it clear that
> only pipe type apr_file_t handles are supported.

makes sense (we already have apr_file_pipe_FOO for several functions
that make sense only for pipe-as-apr_file_t)...

Mime
View raw message