On Mon, Apr 12, 2010 at 9:57 AM, Brian Havard <[email protected]> wrote: > Jeff Trawick wrote: > > On Thu, Apr 8, 2010 at 6:37 AM, Brian Havard <[email protected]> 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)...
