apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@samba-tng.org>
Subject RE: Memory code...
Date Thu, 10 May 2001 14:04:39 GMT
Forwarding this back to the list, somehow we dropped the
list by accident.

Sander

-----Original Message-----
From: Sander Striker [mailto:s.striker@striker.nl]
Sent: 10 May 2001 12:48
To: William A. Rowe, Jr.
Subject: RE: Memory code...


> > David Reid wrote...
> >
> > [...]
> > >> When you find the time could you please change these comments to do
> > >> as they say? :-) I didn't know what your error/warning
> logging functions
> > >> look like (I reckon it is not fprintf(stderr, "some warning"); ), so
> > >> I didn't actually implement it.
> > >
> > > Hmm, again we're a library, not an app...  It's not really
> our job to log
> > > errors is it?  We should simply report the problem and let
> the app decide
> > > what to do about it.
> >
> > The trouble is that it is ok to use this code in this way. It will also
> > succeed. It is just not needed, and therefor overhead. I would just like
> > the users to know this so they can remove this call if they want. Maybe
> > something like APR_VERBOSE as a compile flagg??
>
> If you look at apr_errno, you will notice we finally admit more
> than one value
> can represent a status result.  That even goes for APR_SUCCESS
> (APR_IS_SUCCESS())
> so we could add additional success codes.  I'd suggest an
> APR_NOOP result (also
> a success code) that tells the developer, "Hey, you didn't need
> this call!".

Ok, ack. How would one set this? I'm a bit buried too and at quick
glance this looked an amazing lot of info to swallow :-)

Please, a <5 line example :-)

> But look, if this is a flexible memory system, and the developer
> several layers
> deep doesn't know _which_ kind of memory they are working with,
> then they better
> be calling the entire semantic, no?  And if parts of that
> semantic have no effect
> this time around, you still don't want them coding around it, no?

Right, agreed.

> If they are failures, and you need new APR_Efailure codes, then
> add them.  If you
> want more success (or partial success) codes, add them.  But
> don't harrass the
> developer for using the calls the way they 'ought' to, because we
> don't argue over
> the call setup/teardown around here for the sake of a few ms of
> cpu, we would
> rather concentrate on correctness of code.

*grin* Ok, maybe I get carried away sometimes, but in memory management
cycles count heavy. I wrote a smart memory allocator that does
exponential growth on reallocs. It is really quick. I'll see if I
can port it to a memory system (actually, I know I can, I have to
find the time to do it).

[...]
>> If you always enforce the '== APR_SUCCESS' it is ok. I'm just pointing
>> out that for the users this might be confusing.
>>
>> Maybe a stupid question, but why not introduce an apr_bool_t?
>
> apr_bool_t wouldn't hurt or hinder anything, but it's not a
> legitimate result from
> an apr_function.  The reason is pretty simple.  _Today_ you
> figure, it either worked
> or it didn't, and that's all she wrote.  But _tommorow_ we
> realize that failure is
> actually one of three colors of failure, so we are changing the
> API every few hours
> to keep up with these.  And of course, it's an unneccesary
> inconsistantcy.  Every
> time we have that 'one exception' that 'absolutely' shouldn't be
> an apr_status_t,
> it ends up being an apr_status_t later on :-)

Valid reason :-)

> All result codes are apr_status_t results
>
> BTW ... although I'm buried, it's looking really good from here!
> Please please please,
> agree on the 'shortened names/filenames' and I will be very happy.

I already did, so did Luke and Elrond. Actually I explicitly asked
for it when handing the code over. The long names were just for
clarity when discussing/developing the last couple of weeks (yes,
it took that long, for so little code, because there are some things
that are really tricky ;-).

> Bill

Sander


Mime
View raw message