From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6080 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: In-progress stuff, week of Sept 1 Date: Thu, 4 Sep 2014 21:14:42 -0400 Message-ID: <20140905011442.GA26136@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1409879702 32734 80.91.229.3 (5 Sep 2014 01:15:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Sep 2014 01:15:02 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6093-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 05 03:14:55 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XPi75-0004Cs-GD for gllmg-musl@plane.gmane.org; Fri, 05 Sep 2014 03:14:55 +0200 Original-Received: (qmail 24155 invoked by uid 550); 5 Sep 2014 01:14:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24147 invoked from network); 5 Sep 2014 01:14:54 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6080 Archived-At: 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