apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david reid <da...@jetnet.co.uk>
Subject Re: io abstractions
Date Sun, 25 Jun 2006 20:00:09 GMT
Greg Stein wrote:
> The API is not unified because some platforms (notably, Windows) do
> not allow for unification of the various types. There were problems
> with doing a select() type of operation on files, iirc (tho you could
> with pipes and sockets). For basic read/write, unification is no
> problem. I don't think you can unify the creation, and certainly not
> the type-specific APIs.
> 
> Having N entry points version N enum variatns is no big deal. I would
> prefer the N functions instead of a parameterized function. Note that
> you cannot open "stdout" on Windows unless you use the special
> function.

The plan is to allow for per-type creators, much as we currently do

apr_io_file(...) will create a file io
apr_io_socket(...) a socket etc etc

Then we simply have

apr_read()
apr_write()

and so on. We also have the socket and file ops that can be called on 
any io object, but will only work when they're applicable.

For poll I've added apr_pollset_add() and _remove() which will allow os 
abstraction for building pollsets from varying types of objects. ISTR 
that windows can do this as well as the rest of the sane universe.

I've followed on from Ryan's mail and tried to make the io structures 
"partially" opaque, so some elements are exposed publically.

Typical example

apr_io_file(&io, "test.foo", APR_FOPEN_READ, 0, pool);
printf("filename is %s\n", io->fname);
apr_read(io, buffer, &len);
apr_close(io);

So, not a lot different really :-)

> readv makes sense, as it is easy to simulate if the platform does not 
> have it.

That's what I figured. Was more curious why it wasn't already in. This 
can be handled at the APR level as well, so means only one set of code 
for it.

david

> 
> Cheers,
> -g
> 
> On 6/25/06, david reid <david@jetnet.co.uk> wrote:
>> I've done some work over last 24 hours and have an outline of
>> abstracting the io functions. The aim is to remove the distinction
>> between files, socket and pipes - replacing them with a single apr_io_t
>> type. The exercise of figure out how it should work certainly opened my
>> eyes to how complex we've made the whole thing!
>>
>> I've simply added the new code at present, but in order to gain much
>> we'd need to ditch the older code, hence it's really a change for 2.x
>> and beyond.
>>
>> So far I have basic creation and closing working, but now the
>> architecture is in place getting read/write working shouldn't be hard.
>> There's also a small test app to make sure it's all working as expected.
>>
>> Providing the same level of access we have at present isn't as easy as
>> it looks, and finding a simple api that covers everything may well be
>> impossible, but I'm hopeful we can cover most things under a nice simple
>> api. Exactly how much the perf will be hurt by the changes - I'm not
>> sure at present but may know once I have read/write working.
>>
>> A few things have cropped up though that I'm not really sure about.
>>
>> Why don't we have readv?
>> Why don't we just have a "flagged" version of the functions to open
>> stdxxx? Having both seems a touch silly and dramatic overkill.
>>
>> Unless people scream about this not being the right direction to go I'll
>> try and find some time to progress the work a little more over the next
>> few days.
>>
>> david
>>
> 
> 


Mime
View raw message