apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lucian Adrian Grijincu <lucian.griji...@avira.com>
Subject Re: New Vista APIs
Date Mon, 15 Jan 2007 08:13:06 GMT
My main point for now is that the current API was not designed with
extensibility in mind (but given the fact that all implementations
(except for Vista's new one) provide a means to do "trylock" without any
performance loss to just lock() and release(), no one's to blame. There
was no need for such a new parameter).
Just adding a flag parameter to the apr_thread_rwlock_create and
apr_thread_cond_create constuctors would have been better than the
current situation.

Let's suppose that we have apr_thread_rwlock_create2
(apr_thread_rwlock_t **rwlock,
               apr_int32_t flag,
               apr_pool_t *pool).

and we define two flags to create separate types of objects:
apr_thread_rwlock_t which can and which cannot be used in trylock calls.
the performance of the ones which cannot be used in tyolock calls will
be the same on all platforms except for Vista, where we should see some
sort of improvement.

Garrett Rooney wrote:
> In general, it seems like if we can't provide a cross-platform API
yes we can, we build it upon the current implementation (to which it
will default on platforms that don't have a better performance on
blocking only rwlocks [this currently means only Vista, but who knows
what time may bring] ).
furthermore, this may be implemented without breaking the API: we just
add new constructors. the old ones keep their functionality, nothing breaks.
It's cross-platform and on top it provides the users the possibility to
use a somewhat lighter implementation if they don't require all the
features of a full apr_thread_rwlock_t ( if you only need to power up an
MP3 player why build a personal thermonuclear power plant? Ok, I know
I'm exagerating, and talking without knowing exactly how much
improvement this new API brings, although 'till I get Vista I'll base my
claims on what I read on several sites.).
The thing I don't really get is why the reticence?
Yes, adding a new constructor is kind of ugly ... I don't really like it
myself ... but this is only due to the fact that the original
constructor cannot cope with todays reality.
> with this new low level interface, I don't see the point in using it
> at all...  If it's absolutely going to require new interfaces with
> special cases to make it work, then I'm not sure what the real benefit
as I said, there's only a new constructor to be added. There are no
special cases. The new constructor will make two kinds of objects
blocking and nonblocking. That's it.
Furthermore apr_thread_mutex_t is designed from the start to do the
exact same thing I'm describing here.
It has a flag field. If you want this specific feature set the flag to
some value and we'll use a less performant implementation (Events), but
which gives us the possibility to provide the requested feature.
If you don't need that feature, we'll use this super fast lightweight
solution (CriticalSections). But beware: stuff may break if you use a
CriticalSections-based implementation in improper manners :).
> would be.  I mean this is a "Portable Runtime", after all.
> -garrett

Lucian Adrian Grijincu

View raw message