On 06.07.2020 14:31, Robert Elz wrote:
> Date:Sun, 5 Jul 2020 23:11:44 +0200
> From:Kamil Rytarowski
> Message-ID: <57c15085-dc7d-6c71-1b26-a402839ba...@netbsd.org>
>
> | This is extended to the behavior of "at dlclose() or a normal program
> | termination".
>
>
On Sun, Jul 05, 2020 at 11:11:44PM +0200, Kamil Rytarowski wrote:
> Literal and unextended implementation of the standard happened to be
> unpractical. All/most mainstream users (all other BSDs, Win, Mac, GNU,
> Solaris, ...) diverged from it within the last 20 years.
Funny that you should
Date:Sun, 5 Jul 2020 23:11:44 +0200
From:Kamil Rytarowski
Message-ID: <57c15085-dc7d-6c71-1b26-a402839ba...@netbsd.org>
| This is extended to the behavior of "at dlclose() or a normal program
| termination".
Extended by whom or what? What I quoted was from a
On 05.07.2020 19:42, Robert Elz wrote:
> Date:Tue, 30 Jun 2020 13:43:00 +0200
> From:Kamil Rytarowski
> Message-ID:
>
> I had been ignoring this discussion, but on cleaning up some
> unread list e-mail, I saw this nonsense, and this is just going too far.
>
> |
On Mon, Jul 06, 2020 at 12:42:55AM +0700, Robert Elz wrote:
> Actually, that one is a possible solution. dlclose() is not required
> to do anything at all. While having it never do anything isn't what
> we'd want, having it do nothing if there is a pending atexit function
> from the dynamic
Date:Tue, 30 Jun 2020 13:43:00 +0200
From:Kamil Rytarowski
Message-ID:
I had been ignoring this discussion, but on cleaning up some
unread list e-mail, I saw this nonsense, and this is just going too far.
| This is an extension and extensions are allowed.
That's
On 30.06.2020 15:49, Valery Ushakov wrote:
> On Tue, Jun 30, 2020 at 15:09:14 +0200, Kamil Rytarowski wrote:
>
>> On 30.06.2020 14:24, Valery Ushakov wrote:
>>> On Tue, Jun 30, 2020 at 13:43:00 +0200, Kamil Rytarowski wrote:
>>>
On 30.06.2020 05:16, Jason Thorpe wrote:
>
>> On Jun
On Tue, Jun 30, 2020 at 15:09:14 +0200, Kamil Rytarowski wrote:
> On 30.06.2020 14:24, Valery Ushakov wrote:
> > On Tue, Jun 30, 2020 at 13:43:00 +0200, Kamil Rytarowski wrote:
> >
> >> On 30.06.2020 05:16, Jason Thorpe wrote:
> >>>
> On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote:
>
On 30.06.2020 14:24, Valery Ushakov wrote:
> On Tue, Jun 30, 2020 at 13:43:00 +0200, Kamil Rytarowski wrote:
>
>> On 30.06.2020 05:16, Jason Thorpe wrote:
>>>
On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote:
>
> The atexit() function shall register the function pointed to
On Tue, Jun 30, 2020 at 13:43:00 +0200, Kamil Rytarowski wrote:
> On 30.06.2020 05:16, Jason Thorpe wrote:
> >
> >> On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote:
> >>
> >>>
> >>> The atexit() function shall register the function pointed to by func, to
> >>> be called without arguments
On 30.06.2020 05:16, Jason Thorpe wrote:
>
>> On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote:
>>
>>>
>>> The atexit() function shall register the function pointed to by func, to be
>>> called without arguments at normal program termination. At normal program
>>> termination, all
> On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote:
>
>>
>> The atexit() function shall register the function pointed to by func, to be
>> called without arguments at normal program termination. At normal program
>> termination, all functions registered by the atexit() function shall be
On 29.06.2020 21:36, Jason Thorpe wrote:
>
>> On Jun 29, 2020, at 9:09 AM, Rhialto wrote:
>>
>> But I wonder if there is any standards text that
>> describes whether this particular scenario is supposed to work.
>
> Quoting from "The Open Group Base Specifications Issue 7, 2018 edition"
>
>
>
> On Jun 29, 2020, at 9:09 AM, Rhialto wrote:
>
> But I wonder if there is any standards text that
> describes whether this particular scenario is supposed to work.
Quoting from "The Open Group Base Specifications Issue 7, 2018 edition"
The atexit() function shall register the function
I made a small program reproducing the problem, also with a base system
library. I randomly chose /usr/lib/libtermcap.so as default, but I think
everything that turns up by grep _fini /usr/lib/*.so will do.
Actual output:
$ ./dl
main thread 0x706e490a2800: calling exit()
main thread
On Mon 29 Jun 2020 at 09:55:10 +0200, Rhialto wrote:
> I've looked at __cxa_finalize a bit better, and it seems that the lock
> mutex_lock(&__atexit_mutex); isn't just used to protect running the
> atexit handlers, but even to protect looking at the list of handlers:
> atexit_handler_stack.
> So
On Mon 29 Jun 2020 at 10:39:45 +0200, Martin Husemann wrote:
> On Mon, Jun 29, 2020 at 09:55:10AM +0200, Rhialto wrote:
> > 6. said handler tells the new thread to clean up and finish. One of the last
> >things the thread does, is to dlclose() libavformat.
>
> How can an atexit() handler (or
On Sun 28 Jun 2020 at 23:29:05 +0200, Joerg Sonnenberger wrote:
> On Sun, Jun 28, 2020 at 10:56:01PM +0200, Rhialto wrote:
> > The funny thing is that libavformat uses an atexit handler due to issues
> > with dynamic (un)loading (or so they claim). This is from their file
> >
On 29.06.2020 00:50, Joerg Sonnenberger wrote:
> On Mon, Jun 29, 2020 at 12:34:31AM +0200, Kamil Rytarowski wrote:
>> On 28.06.2020 23:57, Joerg Sonnenberger wrote:
>>> On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote:
On 28.06.2020 23:29, Joerg Sonnenberger wrote:
> It is
On Mon, Jun 29, 2020 at 12:34:31AM +0200, Kamil Rytarowski wrote:
> On 28.06.2020 23:57, Joerg Sonnenberger wrote:
> > On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote:
> >> On 28.06.2020 23:29, Joerg Sonnenberger wrote:
> >>> It is fundamentally wrong to use a handler in a library
On 28.06.2020 23:57, Joerg Sonnenberger wrote:
> On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote:
>> On 28.06.2020 23:29, Joerg Sonnenberger wrote:
>>> It is fundamentally wrong to use a handler in a library that can be
>>> unloaded. Some systems hack around that problem by
On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote:
> On 28.06.2020 23:29, Joerg Sonnenberger wrote:
> > It is fundamentally wrong to use a handler in a library that can be
> > unloaded. Some systems hack around that problem by looping over all
> > atexit handlers on dlclose, but
On 28.06.2020 23:29, Joerg Sonnenberger wrote:
> It is fundamentally wrong to use a handler in a library that can be
> unloaded. Some systems hack around that problem by looping over all
> atexit handlers on dlclose, but that's exactly that, a costly hack. The
> most common way this triggers is a
On Sun, Jun 28, 2020 at 10:56:01PM +0200, Rhialto wrote:
> On Sun 28 Jun 2020 at 22:39:28 +0200, Joerg Sonnenberger wrote:
> > On Sun, Jun 28, 2020 at 10:35:27PM +0200, Rhialto wrote:
> > > I have at hand a program (the current svn trunk of VICE, to be exact)
> > > which does the following:
> > >
On Sun 28 Jun 2020 at 22:39:28 +0200, Joerg Sonnenberger wrote:
> On Sun, Jun 28, 2020 at 10:35:27PM +0200, Rhialto wrote:
> > I have at hand a program (the current svn trunk of VICE, to be exact)
> > which does the following:
> >
> > 1. In the original thread, it dlopen()s libavformat.
> > 2.
On Sun, Jun 28, 2020 at 10:35:27PM +0200, Rhialto wrote:
> I have at hand a program (the current svn trunk of VICE, to be exact)
> which does the following:
>
> 1. In the original thread, it dlopen()s libavformat.
> 2. libavformat establishes an atexit() handler.
> 3. The main thread starts a new
I have at hand a program (the current svn trunk of VICE, to be exact)
which does the following:
1. In the original thread, it dlopen()s libavformat.
2. libavformat establishes an atexit() handler.
3. The main thread starts a new thread, and registers an atexit()
handler to clean up that
27 matches
Mail list logo
