Re: 1.4 release schedule [Was Re: Allowing user data in lt_dlhandles (revisited)]

[Alexandre Oliva]

On Jan  5, 2001, "Gary V. Vaughan" <address@hidden> wrote:

> I am probably not the right person to implement your suggestion, since
> I have never done multi-threaded programming in anger, so my grasp of
> the nuances is somewhat tenuous at best.

This isn't hard at all.  Just call the lock function before any
function that would modify the internal state, and call the unlock
function afterwards.  The pointers to lock functions would initially
be NULL and, if they're NULL, we don't do locking.  We wouldn't be
supplying any locking function ourselves, we'd just let users plug
them in.

> Also, I think this is something we can hold off until after 1.4.

If you say so...  I'd rather have it in, but then, I'm not
implementing them any time soon :-)

>> Yep.  That's why, at the end, I suggested that we always called
>> rpl_realloc(), that would call lt_dlrealloc (or realloc(), if
>> lt_dlrealloc is NULL and lt_dlmalloc == malloc and lt_dlfree == free)
>> only in the portable cases.  If lt_dlrealloc is NULL but lt_dlmalloc
>> or lt_dlfree have been modified, we'd not use realloc(), but implement
>> it in terms of lt_dlfree() and lt_dlmalloc().  How does that sound?

> I am sure it would work, but what does it buy us in preference to
> having rpl_realloc behave as it does now?

The ability of clients to provide a more efficient way to malloc(b),
memcpy(b,a) then free(a).

>> > Also, I didn't want to force the user to maintain an lt_dlrealloc
>> > function pointer by default.
>> 
>> I don't want to force that, only to provide means for the user to
>> supply an implementation that wouldn't have to deal with all the
>> special cases.

> I don't understand what you mean =(O| Sorry.

I mean to always call rpl_dlrealloc internally, so that it only
forwards to lt_dlrealloc the requests that are portable.  In case
lt_dlrealloc is NULL, we fallback to lt_dlmalloc, rpl_memcpy,
lt_dlfree, unless lt_dlmalloc and lt_dlfree are malloc and free,
respectively, in which case we'd use the system's realloc, but, again,
only for the portable kinds of requests.

> Fair enough.  I had a vague recollection that you were worried about
> machines with no realloc() at all.  Silly me =)O|

I don't recall whether realloc is one of those functions that may be
missing on some systems.  This would be of some concern for us, but
nothing a simple autoconf test couldn't take care of.  After all,
we're going to have the fallback to malloc, mempcy and free, anwyay.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me