[Bug libc/173] please consider a qsort_r function, similar to BSD

[Bug libc/173] please consider a qsort_r function, similar to BSD

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2004-08-09 07:45 -------
I'll suspend this bug.  I haven't seen any interest in this code ever and as
Jakub pointed out, there are plenty of methods to make things work with qsort. 
Especially on reasonable systems which have __thread support.

If there should be more interest (which can be demonstrated!) the bug can be
activated again.

Alternatively, you can try to get the function standardized by POSIX.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED


http://sources.redhat.com/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.

[Bug libc/173] please consider a qsort_r function, similar to BSD

[znort99 at yahoo dot com]

------- 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.

[Bug libc/173] please consider a qsort_r function, similar to BSD

[znort99 at yahoo dot com]

------- Additional Comments From znort99 at yahoo dot com  2008-05-04 01:13 -------

Also, re-reading the comment Ulrich made about
why there should be interest in this function,
you may want to take a look at how glib had to
solve the problem. They basically had no choice
but to re-implement quicksort:

http://www.google.com/codesearch?hl=en&q=+g_qsort_with_data+show:KCTGLOhTfYQ:Un7Mc9xTPvU:xo7tCazfQxw&sa=N&cd=1&ct=rc&cs_p=ftp://ftp.gtk.org/pub/gtk/v2.4/glib-2.4.1.tar.bz2&cs_f=glib-2.4.1/glib/gqsort.c#first



-- 


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.

[Bug libc/173] please consider a qsort_r function, similar to BSD

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2008-06-25 18:03 -------
Such a function has been added some time ago.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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.