Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.