Re: [9fans] atexit() atexitdont()
On Fri, Nov 07, 2014 at 08:17:55AM +0100, k...@shike2.com wrote: perhaps a linked list would make sense, but atexits(2) doesn't say which order the functions will be run in. and it doesn't seem like a great idea to depend on atexits running things in a particular order. POSIX says they must be called in reverse order. plan9 isn't POSIX OS :-).
Re: [9fans] atexit() atexitdont()
On 6 November 2014 21:05, Oleg lego12...@yandex.ru wrote: I looked at atexit() and atexitdont() and i don't understand why these functions are implemented with a static array instead of singly linked list? May be somebody with a greater plan9 experience can help me with my question. It might have been to avoid malloc in a fairly low-level function (and of something that will never be freed), or just because it was easier and, frankly, atexit let alone atexitdont aren't used that much. I'd be surprised if any use of atexit alone relied on any particular order, which is why your problem hasn't been noticed. The reverse order makes sense and atexit already does that. It's atexitdont that's wrong. The functions are unlikely to be called from any hot-spot. I'd just make atexitdont copy down the entries after the one deleted.
Re: [9fans] atexit() atexitdont()
On Fri, Nov 07, 2014 at 08:19:05AM +, Charles Forsyth wrote: On 6 November 2014 21:05, Oleg lego12...@yandex.ru wrote: I looked at atexit() and atexitdont() and i don't understand why these functions are implemented with a static array instead of singly linked list? May be somebody with a greater plan9 experience can help me with my question. It might have been to avoid malloc in a fairly low-level function (and of something that will never be freed), If malloc works like in linux (at first invocation allocate more bytes than requested and then each malloc() use this already allocated by kernel area of memory), i think this isn't a big performance impact. or just because it was easier and, frankly, atexit let alone atexitdont aren't used that much. I'd be surprised if any use of atexit alone relied on any particular order, which is why your problem hasn't been noticed. The reverse order makes sense and atexit already does that. It's atexitdont that's wrong. The functions are unlikely to be called from any hot-spot. I'd just make atexitdont copy down the entries after the one deleted. This is according to manual. Because now if we use atexit() with atexitdont() we see the wrong behaviour from manual point of view.
Re: [9fans] atexit() atexitdont()
On 7 November 2014 09:44, Oleg lego12...@yandex.ru wrote: f malloc works like in linux (at first invocation allocate more bytes than requested and then each malloc() use this already allocated by kernel area of memory), i think this isn't a big performance impact. I wasn't really thinking about performance; as I said it's unlikely to be in a critical path. This is according to manual. Because now if we use atexit() with atexitdont() we see the wrong behaviour from manual point of view. Yes, that's why I suggested fixing atexitdont to move any remaining values down the array.
Re: [9fans] atexit() atexitdont()
On 7 November 2014 10:57, Steffen Nurpmeso sdao...@yandex.com wrote: Safety against asynchronous un-/registration can't be it, anyway. No, there's a lock. I meant avoiding too many possible interactions between low-level run-time functions and the rest of the library. (I'd consider atexit and exit to be lower-level functions than malloc.) Since atexit is already used by profile, and is called by _profmain, which is called very early on, putting a call to malloc in that chain means you have to think that much harder about interactions that are already quite subtle. Note that _profmain allocates its memory directly using sbrk, probably for that reason. Suppose I later want to add a malloc profiler, can I call atexit to write the results, or not?
Re: [9fans] atexit() atexitdont()
Oleg lego12...@yandex.ru wrote: |On Fri, Nov 07, 2014 at 08:19:05AM +, Charles Forsyth wrote: | On 6 November 2014 21:05, Oleg lego12...@yandex.ru wrote: | | I looked at atexit() and atexitdont() and i don't understand why these | functions are implemented with a static array instead of singly linked | list? | It might have been to avoid malloc in a fairly low-level function (and of | something that will never be freed), | |If malloc works like in linux (at first invocation allocate more bytes than |requested and then each malloc() use this already allocated by kernel area |of memory), i think this isn't a big performance impact. Safety against asynchronous un-/registration can't be it, anyway. --steffen
Re: [9fans] atexit() atexitdont()
On Fri, Nov 07, 2014 at 11:49:08AM +, Charles Forsyth wrote: On 7 November 2014 10:57, Steffen Nurpmeso sdao...@yandex.com wrote: Safety against asynchronous un-/registration can't be it, anyway. No, there's a lock. I meant avoiding too many possible interactions between low-level run-time functions and the rest of the library. (I'd consider atexit and exit to be lower-level functions than malloc.) Since atexit is already used by profile, and is called by _profmain, which is called very early on, putting a call to malloc in that chain means you have to think that much harder about interactions that are already quite subtle. This is an interesting. With this info the array reordering in atexitdont() looks good comparing to malloc in atexit().
Re: [9fans] atexit() atexitdont()
Not for atexit, but for some other functions, I've had to follow various trails in glibc, and it's just an intricate convoluted nightmare, so that probably colours my view.
Re: [9fans] atexit() atexitdont()
How can i send a patch to 9front? You can file an issue and link to your patch here: http://code.google.com/p/plan9front/issues/list Or you can sign up for the 9front mailing list and post there: http://9front.org/lists.html sl
Re: [9fans] atexit() atexitdont()
On Fri Nov 7 07:26:55 EST 2014, charles.fors...@gmail.com wrote: Not for atexit, but for some other functions, I've had to follow various trails in glibc, and it's just an intricate convoluted nightmare, so that probably colours my view. calling malloc from the atexit path will pull malloc() into every executable. i think this is the real reason not to do this. - erik
Re: [9fans] atexit() atexitdont()
Charles Forsyth charles.fors...@gmail.com wrote: |On 7 November 2014 10:57, Steffen Nurpmeso sdao...@yandex.com wrote: | | Safety against asynchronous un-/registration can't be it, anyway. | |No, there's a lock. I meant avoiding too many possible interactions between I thought more about reentrancy because he referred to Linux. But of course you're right. |low-level run-time |functions and the rest of the library. (I'd consider atexit and exit to be |lower-level functions than malloc.) I do not really agree for the highly integrated and portable solution that i worked with, it was just fine there and splitted into normal and final handlers. But.. |Since atexit is already used by profile, and is called by _profmain, which |is called very early on, |putting a call to malloc in that chain means you have to think that much |harder about interactions that are already quite subtle. |Note that _profmain allocates its memory directly using sbrk, probably for |that reason. |Suppose I later want to add a malloc profiler, can I call atexit to write |the results, or not? It seems you can add an atom and it works without spending any further thought. That is cool. --steffen
Re: [9fans] atexit() atexitdont()
On Fri, Nov 07, 2014 at 02:53:11PM -0500, erik quanstrom wrote: On Fri Nov 7 07:26:55 EST 2014, charles.fors...@gmail.com wrote: Not for atexit, but for some other functions, I've had to follow various trails in glibc, and it's just an intricate convoluted nightmare, so that probably colours my view. calling malloc from the atexit path will pull malloc() into every executable. i think this is the real reason not to do this. That's interesting. Is malloc() so huge to worry about it?
[9fans] atexit() atexitdont()
Hi, all.
I looked at atexit() and atexitdont() and i don't understand why these
functions are implemented with a static array instead of singly linked list?
May be somebody with a greater plan9 experience can help me with my question.
If i do:
#include u.h
#include libc.h
void f1(void)
{
print(f1\n);
}
void f2(void)
{
print(f2\n);
}
void main(int, char**)
{
atexit(f1);
atexit(f2);
atexit(f1);
atexitdont(f2);
atexit(f2);
exits(nil);
}
i get:
f1
f2
f1
instead of:
f1
f1
f2
because of atexit.c source code.
Thanks.
Re: [9fans] atexit() atexitdont()
On Thu Nov 6 16:07:56 EST 2014, lego12...@yandex.ru wrote: Hi, all. I looked at atexit() and atexitdont() and i don't understand why these functions are implemented with a static array instead of singly linked list? May be somebody with a greater plan9 experience can help me with my question. perhaps a linked list would make sense, but atexits(2) doesn't say which order the functions will be run in. and it doesn't seem like a great idea to depend on atexits running things in a particular order. - erik
Re: [9fans] atexit() atexitdont()
according to the man page: Before calling _exits with msg as an argument, exits calls in reverse order all the functions recorded by atexit. so i think your result should be f2, f1, f1. On Thu, Nov 6, 2014 at 1:26 PM, erik quanstrom quans...@quanstro.net wrote: On Thu Nov 6 16:07:56 EST 2014, lego12...@yandex.ru wrote: Hi, all. I looked at atexit() and atexitdont() and i don't understand why these functions are implemented with a static array instead of singly linked list? May be somebody with a greater plan9 experience can help me with my question. perhaps a linked list would make sense, but atexits(2) doesn't say which order the functions will be run in. and it doesn't seem like a great idea to depend on atexits running things in a particular order. - erik
Re: [9fans] atexit() atexitdont()
i'm wondering if print is the right instrument for knowing the order is right. On Thu, Nov 6, 2014 at 1:42 PM, Skip Tavakkolian skip.tavakkol...@gmail.com wrote: according to the man page: Before calling _exits with msg as an argument, exits calls in reverse order all the functions recorded by atexit. so i think your result should be f2, f1, f1. On Thu, Nov 6, 2014 at 1:26 PM, erik quanstrom quans...@quanstro.net wrote: On Thu Nov 6 16:07:56 EST 2014, lego12...@yandex.ru wrote: Hi, all. I looked at atexit() and atexitdont() and i don't understand why these functions are implemented with a static array instead of singly linked list? May be somebody with a greater plan9 experience can help me with my question. perhaps a linked list would make sense, but atexits(2) doesn't say which order the functions will be run in. and it doesn't seem like a great idea to depend on atexits running things in a particular order. - erik
Re: [9fans] atexit() atexitdont()
On Thu, Nov 06, 2014 at 04:26:04PM -0500, erik quanstrom wrote: On Thu Nov 6 16:07:56 EST 2014, lego12...@yandex.ru wrote: Hi, all. I looked at atexit() and atexitdont() and i don't understand why these functions are implemented with a static array instead of singly linked list? May be somebody with a greater plan9 experience can help me with my question. perhaps a linked list would make sense, but atexits(2) doesn't say which order the functions will be run in. It say - in reverse order. and it doesn't seem like a great idea to depend on atexits running things in a particular order. Why? There are various situations...
Re: [9fans] atexit() atexitdont()
On Thu, Nov 06, 2014 at 01:44:30PM -0800, Skip Tavakkolian wrote: i'm wondering if print is the right instrument for knowing the order is right. You are right, but in this case it's irrelevant. The atexit.c source code is pretty disambiguous.
Re: [9fans] atexit() atexitdont()
perhaps a linked list would make sense, but atexits(2) doesn't say which order the functions will be run in. and it doesn't seem like a great idea to depend on atexits running things in a particular order. POSIX says they must be called in reverse order.
