This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/173] please consider a qsort_r function, similar to BSD
- From: "znort99 at yahoo dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 4 May 2008 00:55:11 -0000
- Subject: [Bug libc/173] please consider a qsort_r function, similar to BSD
- References: <20040519072537.173.stevenj@mit.edu>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From znort99 at yahoo dot com 2008-05-04 00:55 -------
I think this should be re-opened.
Contrary to the argument presented in this bug, it is
actually really hard to properly implement qsort_r on
top of qsort (short of using a trampoline or entirely
re-coding quicksort).
Rationale against the arguments presented:
>There are already now ways how to do that even without qsort_r:
>a) store the state to __thread variables
This may be thread safe, but it is not re-entrant,
which is what the original poster needed (and what
I find myself needing as well)
>b) use GCC nested functions
This obliges you to write GCC specific code.
As elegant as this solution may be, and as much as we all
like GCC, this is a non standard feature and makes your code
unportable to non-GCC environments.
>c) use pthread_getspecific
Again an ugly band-aid (in this case a global variable
hidden in a posix thread function). Depending on your OS
and implementation of posix threads, this might also very
well be dog slow.
Finally: this is again not reentrant.
d) use locking around the qsort invocation
Again: not re-entrant. If the compare function
finds itself in need of sorting against a second
key to get an answer, you're dead in the water.
Please, please, please re-consider making
qsort_r part of glibc.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|SUSPENDED |NEW
http://sourceware.org/bugzilla/show_bug.cgi?id=173
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.