This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: aio directions...


Andreas Jaeger wrote:

> Tom Gall <tom_gall@vnet.ibm.com> writes:
>
> Some of your patches look bogus as pointed out by Ulrich and Roland
> already.  For example NULL is not a valid pointer, glibc never checks
> for it.

Hi Andreas, (Small world!)

  We're fixing the formating and such. (no donut for me!
bad kernel hacker!)

  In the context of checking for NULL for valid pointers, actually
glibc does do this in spots. I drew inspiration from the following
macro from stdio/stdio.h

    218 /* Nonzero if STREAM is a valid stream.
    219    STREAM must be a modifiable lvalue (wow, I got to use that
term).
    220    See stdio/glue.c for what the confusing bit is about.  */
    221 #define
__validfp(stream)                                                     \
    222   (stream != NULL
&&                                                          \
    223    ({ if (stream->__magic ==
_GLUEMAGIC)                                      \
    224         stream = *((struct { int __magic; FILE **__p; } *)
stream)->__p;      \
    225       stream->__magic == _IOMAGIC; }))

   which is used quite a lot in the stdio directory. For example:
stdio/fread.c

     28 fread (p, size, nmemb, stream)
     29      void *p;
     30      size_t size;
     31      size_t nmemb;
     32      register FILE *stream;
     33 {
     34   register char *ptr = (char *) p;
     35   register size_t to_read = size * nmemb;
     36   size_t bytes = to_read;
     37
     38   if (!__validfp (stream) || !stream->__mode.__read)
     39     {
     40       __set_errno (EINVAL);
     41       return 0;
     42     }

etc etc......

   With aio_* having a control block that is conceptually much
like the various stdio f*  functions I presumed it was a good
course of action to take.

    We're more than happy to rip out the check from the
next patch.

> > The next step that we're intending on taking with regards to
> > aio is to try and address the performance
> > question, pushing a portion of the functionality into the
> > kernel.  We also see a need for some "add-on" functions
> > since the polling aspects of AIO seem to be rather popular
> > to various crowds.
>
> What add-on functions do you need?

What i was thinking was in other aio implementations they tend to
take somewhat of a different swizzle on the aio_* interface.
Generally the database crowd wants more in the areas of
polling and so on.

 I was thinking we would post a design proposal here and see how
it goes. Probably something for after OLS.

Regards,

Tom

--
Tom Gall - PPC64, PPC, Embedded  "Where's the ka-boom? There was
Linux Technology Center           supposed to be an earth
(w) tom_gall@vnet.ibm.com         shattering ka-boom!"
(w) 507-253-4558                 -- Marvin Martian
(h) tgall@rochcivictheatre.org
http://www.ibm.com/linux/ltc




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]