[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140905011442.GA26136@brightrain.aerifal.cx>
Date: Thu, 4 Sep 2014 21:14:42 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: In-progress stuff, week of Sept 1
We have a lot of open patch and feature requests, some big projects
(C11), and other random stuff still under consideration for this
release cycle, so I'm going to try to summarize what I'm aware of and
what's likely to make it in.
First, things that definitely are going in this release cycle:
- Jens Gustedt's C11 threads: From discussion it's ready, but the last
iteration of the patches added more gratuitous changes at the same
time it removed others. Jens is going to be less available for a
while, so I'm going to finish getting the patches ready to commit,
but it's going to take a little work going back and reviewing the
email threads to determine what was the outcome of discussion versus
what's new, and among what's new, whether it's essential or side
changes orthogonal to adding C11 threads.
- fgets at EOF: The proposed fix by nsz is right, but I think we
should also address the issue of the missing lock in the n=1 case.
- dn_expand issues: Potentially serious bugs that need to be fixed
ASAP. nsz and I are working on them right now.
- nsz's LFS64 fixes: Should be straightforward to review and commit.
- Alexander Monakov's "New static analysis results": These probably
indicate a few minor bugs which should be easy to fix.
And one more that's iffy:
- Felix Janda's login_tty patch: While on the surface this is a short,
simple patch, I think more consideration is still needed for what
happens in the error cases. These legacy functions that lack any
formal specification, especially for how errors are handled, are
always a big pain to add.
Finally, here are the non-trivial open items that probably won't make
it into this release:
Jens Gustedt's work on cond var improvements:
Based on our previous discussions, I think the proposed changes are
valid, but I also think they make the code mildly more complex. So
they're probably justified only if we can measure a performance
improvement under at least some usage cases. The ideal way I'd like to
move forward with these is with some tests that could measure the lock
contention from the race between signaling and early waiter exit
(timeout or cancellation).
Alexander Monakov's work on semaphores:
It's all very interesting, but would take considerable further review
to convince me that it's safe, and would also need some benchmarking
to establish whether it's desirable, even if it is safe. I hope
something comes of all the work he's put into it though (either a
positive or negative result about its benefit would be "something",
here), rather than just remaining unevaluated.
Bobby Bingham's work on qsort:
This is also promising, but I've seen mixed claims about performance
relative to the current smoothsort. More data is needed to evaluate
it, I think.
My further fix for cond var wait cancellation:
I have a patch, but it requires setjmp/longjmp and makes typical usage
nontrivially slower. I could go ahead and commit it for now, and fix
the performance regression later, but the clean, free fix depends on
the new cancellation mode I want to add.
My new cancellation mode:
This is actually going to be an almost-trivial patch when I write it,
but I want to have the time to give it the attention it needs, with
the hopes of producing something that can also be a public interface
proposal.
Additional roadmap items not mentioned above, and for which work has
not yet started, are probably going to get pushed back again into the
next release cycle.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
