From: Jens Gustedt <jens.gustedt@inria.fr>
To: musl@lists.openwall.com
Subject: Re: [PATCH] fix atexit when it is called from an atexit handler
Date: Thu, 23 Jul 2015 09:19:13 +0200 [thread overview]
Message-ID: <1437635953.3270.3.camel@inria.fr> (raw)
In-Reply-To: <1437630843.3270.1.camel@inria.fr>
[-- Attachment #1.1: Type: text/plain, Size: 1643 bytes --]
Am Donnerstag, den 23.07.2015, 07:54 +0200 schrieb Jens Gustedt:
> I'd think this could be done even simpler by running the handlers in
> batches. ...
I checked, the strict ordering constraints for the handlers don't
allow for such a strategy, so forget it.
Looking at the code, I am a bit uncomfortable with the idea of a
potentially unlimited number of calloc calls during exit. I think it
would be good if we could restrict the maximal number of successful
calls to atexit during exit to 32. A calloc-free strategy could be to
save head to a tmp a the beginning of processing and to provide a
`struct fl` table on the stack of __funcs_on_exit.
> A similar improvement could be done for at_quick_exit. There I think
> it makes not much sense accepting new handlers during processing. So
> the strategy could just be
>
> (i) Take the lock and save count in a tmp
> (ii) set count to 32
> (iii) unlock
> (iv) do the processing
>
> But looking at it, I think that one can even be more improved. We
> could just use count as atomic, and so we wouldn't need a lock.
> I can prepare a patch for that, if you like.
Since this is fairly simple, I just did it. Please find a new version
attached. (too much changes, a patch makes no sense.) This compiles,
but I have no code to test this.
Jens
--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
[-- Attachment #1.2: at_quick_exit.c --]
[-- Type: text/x-csrc, Size: 679 bytes --]
#include <stdlib.h>
#include "atomic.h"
#include "libc.h"
#define COUNT 32
static void (*funcs[COUNT])(void);
static volatile int count;
void __funcs_on_quick_exit()
{
void (*func)(void);
/* No need for atomics here, we are alone. */
int total = count;
/* The counter might have been overrun at some time. */
if (total > 32) total = 32;
else count = 32;
while (total > 0) {
func = funcs[--total];
func();
}
}
int at_quick_exit(void (*func)(void))
{
int pos = a_fetch_add(&count, 1);
if (pos >= 32) {
if (pos > INT_MAX/2) pos = 32;
return -1;
}
funcs[pos] = func;
/* make sure that the effect is visible to everybody */
a_barrier();
return 0;
}
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2015-07-23 7:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 23:44 Szabolcs Nagy
2015-07-23 1:18 ` Rich Felker
2015-07-23 3:07 ` Szabolcs Nagy
2015-07-23 5:54 ` Jens Gustedt
2015-07-23 7:19 ` Jens Gustedt [this message]
2015-07-23 19:58 ` Rich Felker
2015-07-23 21:51 ` Jens Gustedt
2015-07-24 0:16 ` Szabolcs Nagy
2015-07-24 6:52 ` Jens Gustedt
2015-07-24 10:53 ` Szabolcs Nagy
2015-07-24 16:01 ` Rich Felker
2015-07-24 21:25 ` 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=1437635953.3270.3.camel@inria.fr \
--to=jens.gustedt@inria.fr \
--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).