apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: more notes on the apr_time_t issue
Date Sun, 14 Jul 2002 18:25:12 GMT

Apologizing now, my comments yesterday stemmed from having a VERY bad.
I let it bleed into my postings, and that was wrong.

> From: 'Aaron Bannert' [mailto:aaron@clove.org]
> 
> On Sat, Jul 13, 2002 at 11:07:57AM -0700, Ryan Bloom wrote:
> > Screw that.  I have lost votes before, and I can accept that.  What
is
> > pissing me off is that the obvious majority would rather keep
> > apr_time_t, but because of a stupid veto, we are being forced to
change
> > the name.
> 
> "Stupid veto?" Pardon me, but that is the entire point of a veto.
> I have a problem with one of the solutions, and I have a valid
> technical reason (that you may not agree with). Let's work together
> to fix the problem in a way we'll all be happy with.

My biggest problem is that this is just getting more and more complex,
and the conversation is almost impossible to follow.  To the best of my
knowledge (from trying to follow the conversation), at this point, we
are talking about:

Apr_busec_time_t and apr_busec_span_t

So, simple question:  What is a busec?  I obviously know the answer, it
is a binary usec.  How many of APR users do you honestly expect to look
at busec and think that?

Now, we are also talking about having macros to convert to and from
decimal time values.  So, that would essentially be:

Apr_busec_sec
Apr_busec_usec
Apr_busec_msec

And corresponding reverse macros:

Apr_sec_busec
Apr_usec_busec
Apr_msec_busec

A way to compare and operate on time:

Apr_busec_add
Apr_busec_sub

Now, we still need a way to get to the current time:

Apr_busec_now

Convert to a human-readable form:

Apr_time_exp_tz
Apr_explode_time
Apr_time_exp_gmt
Apr_time_exp_lt
Apr_explode_localtime
Apr_time_exp_get

Convert from human-readable to apr:

Apr_implode_gmt
Apr_implode_time
Apr_time_imp_tz

Convert to strings:

Apr_rfc22_date
Apr_ctime
Apr_strftime

And finally sleep:

Apr_sleep

22 functions/macros to deal with time. 8 of those are because we are
storing time in a format that nobody else expects.

How does apr_poll deal with time?  Does it use apr_busec_interval_t or
"number of seconds to wait"?  If it uses apr_busec_interval_t, then
every single call to poll (and every other apr function that accepts a
timeout arg) becomes:

Apr_poll(pollset, 1, &nsds, apr_sec_busec(5));

If it accepts "number of seconds to wait", then EVER apr function that
accepts a timeout arg needs to do its own conversion.  Which, BTW is a
bad idea, because keeping it straight when you are using apr_busec_t and
when you are using "number of seconds" inside the library will be very
difficult to keep track of, and it is almost guaranteed to cause bugs.

Either one of these solutions is most likely going to cause enough pain
to the developer that APR's time code will be used rarely, IMHO.

> > We have provided mechanisms for users to determine if
> > their version of APR matches the installed version.
> 
> I know of no APR apps that are currently using these mechanisms,
including
> httpd. Do you?

We provide it, because apps need to start to use it.  The timing change
would be the perfect excuse to start enforcing it.

> > Vetos used to be rare, now they are common.  That stops debate,
because
> > a veto can only be removed by the person who issued it.  I have a
> > problem with the frequency with which vetos are used in APR and
httpd
> > development today.  We are all supposed to be working together to
solve
> > a problem, vetos are meant to be used when rational discussion
DOESN'T
> > come up with a solution.  Instead, we use them to head off possible
> > solutions that we don't like.
> 
> That is exactly what they are for. Rather than let people go through
> the work to come up with something that will be later vetoed, we state
> early what we would have a problem with and try to work around it.
This

No.  State it with a comment in e-mail, not a veto.  A veto is too
confrontational, and they are usually put out there when emotions are
high.  There was a threatened veto on apr_wait_for_io_or_timeout using
apr_poll, because the code would be ugly.  But I ignored the veto, and
re-wrote apr_poll, which, I think everybody will agree, was the best way
to solve the problems.  Vetos stop work which could be correct.
Discussions allow work to continue taking everybody's opinions into
account.  If you lay a veto at the beginning of the discussion, it isn't
worth following that logic at all anymore, which can stop some very
useful ideas from being put out and followed.  If you have a civil
conversation without the vetos, your opinion continues to be heard, but
it is heard in a non-confrontational way, and the discussions keep
moving forward.  Who knows, you may find that you can live with what you
were going to veto, because of some of the other benefits of it.

What if somebody had volunteered to write a script that converted all
current implementations of apr_time_t to the binary format?  Would that
have resolved your veto?  We'll never know, because the veto was thrown
out, so the apr_time_t name was dropped as an option very early on.  I
don't honestly think such a script could be 100% accurate, but that is
just the first thing that came to my head.  Maybe would could have had:

#ifndef NEW_TIME_FMT 
#error "Please convert you code to use busec's
#endif

And removed the #ifndef after a month or two.  Would that have resolved
the veto.  Vetos stop conversations, whereas opinions and civil
discussion allow them to continue.  The earlier a veto is thrown, the
more likely that a perfectly valid technical solution will not be
discussed.

Ryan


Mime
View raw message