libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rewrite try_dlopen (2)


From: Bob Friesenhahn
Subject: Re: rewrite try_dlopen (2)
Date: Tue, 5 Oct 2004 09:47:36 -0500 (CDT)

On Tue, 5 Oct 2004, Ralf Wildenhues wrote:

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.

I was not aware of this TODO section. The purpose/need for async-signal-safe functions is for them to be safe for use from within signal handlers. It has nothing to do with usability outside of signal handlers. Libltdl does not use any signal handlers.

In what case might someone want to invoke libltdl functions from a signal handler? I think that this would be a very unwise thing to do, regardless of implementation.

The list of async-safe functions is pretty short and does not include dlopen()/dlclose(). If the objective is for libltdl's functions to be async-safe, then great care would need to be taken with the implementation.

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?

Mmap (or equivalent) is generally available on systems which support shared/dynamic libraries and virtual memory. Other than embedded type systems (e.g. LynxOS), I have not encountered a modern system which does not support memory mapped files. Mmap is less portable than read/write, which is less portable than stdio.

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]