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

[Gary V. Vaughan]

On Fri, Jan 05, 2001 at 08:10:29AM -0200, Alexandre Oliva wrote:
> On Jan  5, 2001, "Gary V. Vaughan" <address@hidden> wrote:
> 
> > gmodule *is* thread safe, but only becaus it does mutex locking
> > around the body of most of it's calls.  If this can all work, I
> > think we are okay...
> 
> We should probably export mutex lock/unlock pointers-to-functions, so
> that an application uses a single lock/unlock mechanism for libltdl.
> Think of multiple clients within a single multi-threaded application,
> each one using a different mutex to control access to libltdl.  This
> is certainly not going to work.

Hmm.  Good point.  For the moment, I think we will need to mandate
that if an application needs to use libltdl with mutexes, all clients
have to use the same wrapper functions in order to share a single
mutex.

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.  Also, I think this is
something we can hold off until after 1.4.  I am prepared to give it a
try after we have the multi-language branch merged back into the trunk.

While we are on the subject, I am planning to do the following few
tasks, and then I think we'll be in good shape for a release:

  i)   Provide enough functionality to satisfy soon-to-be-m4-1.5
  ii)  Add any functionality required to support a reimplementation
       of gmodule for glib-2.0
  iii) Drain the patch queue.
  iv)  Get dll's working under cygwin again.
  
I'd like to fit 2 beta releases between now and 1.4:  The first when
(i) and (ii) seem to be in place, and another when we think 1.4 looks
like it is done.

> >> And, in fact, it might use lt_dlrealloc only in case it would have
> >> called realloc(), so that we save users from having to duplicate
> >> all the logic of free/malloc in realloc.
> 
> > I didn't do this because I wanted to be able to rely on the particular
> > semantics I have implemented
> 
> 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?

> > trash the contents of the original pointer if there is not enough
> > memory to create a new one).
> 
> Really?  Ouch!  That's a good reason to never use realloc().

The only real example I know of is my now defunct Unisys SysV box
circa 1983.  It only had 1Mb of memory (on two 512Kb memory cards,
each the size of a sheet of A4 paper!), and 4Mb of swap (10% of the
hard disk) and used to actually hit the limit quite often.  I don't
know whether any modern machines are this bad, or indeed whether it is
likely that virtual memory will actually run out.

> > 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.  Surely, if I rely on the
special case semantics (NULL ptr, and 0 size arguments) inside
libltdl, the user must supply a realloc that behaves the same.  This
means they will need to test the system realloc, and only use it if it
complies.  I must have the wrong end of the stick...

> > Can you refresh my memory over what your concern's with realloc
> > were, from the last time I submitted a patch to add `lt_dlrealloc =
> > realloc'?
> 
> Portability regarding behavior regarding NULL pointers and zero sizes,
> IIRC.

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

Cheers,
        Gary.
-- 
  ___              _   ___   __              _         mailto: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc