[9fans] atexit() & atexitdont()

[9fans] atexit() & atexitdont()

[Oleg]

  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()

[erik quanstrom]

On Thu Nov  6 16:07:56 EST 2014, lego12239@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()

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

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 <quanstro@quanstro.net>
wrote:

> On Thu Nov  6 16:07:56 EST 2014, lego12239@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
>
>

[-- Attachment #2: Type: text/html, Size: 1390 bytes --]

Re: [9fans] atexit() & atexitdont()

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

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.tavakkolian@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 <quanstro@quanstro.net>
> wrote:
>
>> On Thu Nov  6 16:07:56 EST 2014, lego12239@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
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 1913 bytes --]

Re: [9fans] atexit() & atexitdont()

[lego12239]

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()

[Oleg]

On Thu, Nov 06, 2014 at 04:26:04PM -0500, erik quanstrom wrote:
> On Thu Nov  6 16:07:56 EST 2014, lego12239@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()

[k0ga]

> 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.

Re: [9fans] atexit() & atexitdont()

[Oleg]

On Fri, Nov 07, 2014 at 08:17:55AM +0100, k0ga@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()

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On 6 November 2014 21:05, Oleg <lego12239@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.

[-- Attachment #2: Type: text/html, Size: 1374 bytes --]

Re: [9fans] atexit() & atexitdont()

[Oleg]

On Fri, Nov 07, 2014 at 08:19:05AM +0000, Charles Forsyth wrote:
> On 6 November 2014 21:05, Oleg <lego12239@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()

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

On 7 November 2014 09:44, Oleg <lego12239@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.

[-- Attachment #2: Type: text/html, Size: 1450 bytes --]

Re: [9fans] atexit() & atexitdont()

[Oleg]

On Fri, Nov 07, 2014 at 10:22:26AM +0000, Charles Forsyth wrote:
> Yes, that's why I suggested fixing atexitdont to move any remaining values
> down the array.

How can i send a patch to 9front?

Re: [9fans] atexit() & atexitdont()

[Steffen Nurpmeso]

Oleg <lego12239@yandex.ru> wrote:
 |On Fri, Nov 07, 2014 at 08:19:05AM +0000, Charles Forsyth wrote:
 |> On 6 November 2014 21:05, Oleg <lego12239@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()

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

On 7 November 2014 10:57, Steffen Nurpmeso <sdaoden@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?

[-- Attachment #2: Type: text/html, Size: 1212 bytes --]

Re: [9fans] atexit() & atexitdont()

[Oleg]

On Fri, Nov 07, 2014 at 11:49:08AM +0000, Charles Forsyth wrote:
> On 7 November 2014 10:57, Steffen Nurpmeso <sdaoden@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()

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 177 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 303 bytes --]

Re: [9fans] atexit() & atexitdont()

[erik quanstrom]

On Fri Nov  7 07:26:55 EST 2014, charles.forsyth@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()

[Oleg]

On Fri, Nov 07, 2014 at 02:53:11PM -0500, erik quanstrom wrote:
> On Fri Nov  7 07:26:55 EST 2014, charles.forsyth@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?

Re: [9fans] atexit() & atexitdont()

[Steffen Nurpmeso]

Charles Forsyth <charles.forsyth@gmail.com> wrote:
 |On 7 November 2014 10:57, Steffen Nurpmeso <sdaoden@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()

[sl]

> 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