Re: rewrite try_dlopen (2)

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Tue, Oct 05, 2004 at 04:17:37PM CEST:
> On Tue, 5 Oct 2004, Ralf Wildenhues wrote:
> >
> >The getline clone get_line that fell out of this change could in
> >principle be replaced by the glibc one (and LIBOBJed on non-glibc
> >systems), and its current implementation is still ugly, but I did
> >not want to work on this now.  I'd rather do that together with
> >switching ltdl from stdio to fd IO sometime soon (as requested).
> 
> I am not aware of any advantage to using Unix I/O rather than ANSI C 
> standard stdio for reading/writing small files.  C's stdio is buffered 
> while read/write are not buffered.  Efficiently using read/write 
> requires that the application/library provide its own buffering 
> mechanism and parsing functions, which will surely increase code size 
> and maintenance.

Are you arguing that we should disregard this feature request?  From
libtool/TODO section 2.5:

| * Godmar Back writes:
|   libltdl uses such stdio functions as fopen, fgets, feof, fclose, and others.
|   These functions are not async-signal-safe. While this does not make
|   libltdl unusable, it restricts its usefulness and puts an
|   unnecessary burden on the user.
|  
|   As a remedy, I'd recommend to replace those functions with functions
|   that POSIX says are async-signal-safe, such as open, read, close.
|   This will require you to handle interrupted system calls and implement
|   fgets, but the former isn't hard and there's plenty of implementations
|   out from which you can steal the latter.
|  
|   I believe relying on async-signal-safe functions to the greatest extent
|   possible would greatly improve libltdl's ability to be embedded in and
|   used by other systems.


> There are cases where Unix I/O is to be preferred over stdio but 
> parsing tiny text files is not one of those cases.  In order to 
> effectively use Unix I/O one would want to first slurp the entire file 
> into memory since .la files are smaller than a typical disk block. 
> If Unix I/O is even to be considered, then why not consider using 
> memory-mapped files (e.g mmap())?

I fully acklowledge your point that Unix I/O might not be more effective
here (and more work as well).  It's not too hard to do that right,
though.  But first a decision has to be made whether Unix IO is
desirable in libltdl.

BTW, would mmap be portable enough to be usable?

Regards,
Ralf