mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: In-progress stuff, week of Sept 1
Date: Thu, 4 Sep 2014 21:14:42 -0400	[thread overview]
Message-ID: <20140905011442.GA26136@brightrain.aerifal.cx> (raw)

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


             reply	other threads:[~2014-09-05  1:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05  1:14 Rich Felker [this message]
2014-09-05  1:57 ` Szabolcs Nagy
2014-09-05  8:47   ` Rich Felker
2014-09-05  9:07     ` Alexander Monakov
2014-09-05 16:02       ` Rich Felker
2014-09-05 17:40         ` Alexander Monakov
2014-09-05 18:06           ` Rich Felker
2014-09-05  7:41 ` Jens Gustedt
2014-09-05  8:32   ` Rich Felker
2014-09-05  9:27     ` Jens Gustedt
2014-09-05 16:45       ` Rich Felker
2014-09-05 17:09         ` Alexander Monakov
2014-09-06  7:04         ` Jens Gustedt
2014-09-05  8:49 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140905011442.GA26136@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).