Re: Is there a wishlist?

> I thought I could work on some features, but I just wanted to know whether
> you'd even want them (I dislike to waste my time).

> I planned on doing:

> - dynamic interpreter support

> I.e. run the interpreter like a program and let the first argument be the
> program to run. Like ld.so from glibc can. Would be good for testing. Well
> it also won't be exactly the same as running as loader. But the glibc guys
> couldn't do that as well:

We are about saving space, and this does not strike me as a feature that
is needed in production environments.  We could make it conditional, but
I don't really see the appeal of it in the first place.

> $ /lib/ld*.so /bin/readlink /proc/self/exe
> /lib/ld-2.11.2.so

> - thread safe errno

> Either I didn't look in the right places or handling of errno really isn't
> thread safe in dietlibc. How about doing something similar to the glibc,
> just not as broken? I thought of

You probably didn't look deep enough.
The errno and errno_location in libc are overridden by the definitions
from libpthread, and those are thread-safe.

> Plus, while scooping around with that matter, I stumbled across a pretty
> strange bug. Consider this source code:

> When compiled against glibc, it runs. When compiled against dietlibc (with
> -pthread and -lpthread), the code fails after the second printf. According
> to strace, the last system call is sched_yield(). After that, no signal,
> no exit(), nothing. Just went dead. How can a process exit without calling
> exit() or being signalled?

Sigh.  Looks like a segfault in the thread cleanup code while trying to
write errno_location of a thread that is apparently cleaned up already.

> - introduce futexes
> I noticed in libpthread that the mutex locking stuff is done via busy
> waits. How about introducing futexes there? Instead of looping
> indefinitely, we just have all of the threads queue up and wait to be
> woken. It looks easy enough to me. It won't need to be as fancy as the
> glibc implementation, where they included a third state for the mutex.
> "Locked and there's processes waiting" Now the problem is, you could only
> do that with either a more powerful atomic instruction, like compare and
> swap, or by wasting some space. Plus it increases complexity of the code,
> just to save one system call. And here I was thinking system calls are
> cheap.

The whole pthread code is ancient and could be significantly improved by
using futexes and the new clone semantics of 2.6.  The question is: can
we do it while maintaining backwards compatibility to 2.4?  Should we?
Is anybody really still using pre-2.6 kernels?

Felix