Re: Is there a wishlist?

On 03.03.2011 18:15, Felix von Leitner wrote:
>> 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.
> 

Well, the idea came to me when I read

if (loadaddr == 0) {
    pf("\ndiet libdl.so/dynamic-linker can't be started as a program
!\n\n SORRY...\n\n");
    return (unsigned long)_DIE_;
}

I thought, no need to be sorry, just fix it.

But it seems that the code needed for this would be somewhat bigger than
that string.

>> - thread safe errno
> 
[...]
>
> 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.
> 

Ah, thanks for the pointer, now I found it.

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

And that would kill strace? Which, by the way, exits normally. I straced
strace and here's the tail of that log:

write(3, "kill(1294, SIGRT_31", 19)     = 19
ptrace(PTRACE_SYSCALL, 1293, 0x1, SIG_0) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGTRAP}], __WALL, NULL) = 1293
ptrace(PTRACE_PEEKUSER, 1293, 8*ORIG_RAX, [0x50d]) = -1 ESRCH (No such
process)
--- SIGCHLD (Child exited) @ 0 (0) ---
ptrace(PTRACE_SYSCALL, 1293, 0x1, SIG_0) = -1 ESRCH (No such process)
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], __WALL, NULL) = 1293
write(3, ")                    = ? <unavai"..., 39) = 39
exit_group(0)                           = ?

So strace does get notified about the test program exiting.

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

Well, since we already have a version that works (however badly), we
could make it conditional. I propose a new feature macro in
dietfeatures.h, named WANT_26. Then we can make it conditional on that
whether to use kernel 2.6 features.

> Felix

Markus
-- 
() ASCII Ribbon Campaign
/\ Against HTML in Mail and News