Subject: Re: [boost] "peer reviewed" - Rights and responsibilities of maintainers
From: Robert (r.firl_at_[hidden])
Date: 2018-10-17 19:51:10
On 10/17/2018 2:06 AM, Alexander Grund via Boost wrote:
>> Again, though, this is a side track.Â My main point is that if you
>> find yourself asking "has this object been destroyed?" then it's
>> usually a sign of a more fundamental lifetime mismatch, and it's
>> probably worthwhile exploring that.
> This is true. But:
> a) is_destroyed is part of the public interface of Boost.Serialization
> (see the docs) and it doesn't return true when it should as shown by
> #110 even in the case of a simple executable.
> b) In the case I described and tested with #111 (and now even with #128)
> There are 2 shared libraries with their own instances of the singletons
> (this can be checked by debugging the ctor/dtor of them). The lifetime
> mismatch happens due to "some linux mechanism" destroying same types
> from different libraries at the same time invalidating the expectation
> of each library. Example (actually witnessed by printf-debugging)
> singleton<A> (0xlib1)
> singleton<B> (0xlib1)
> singleton<A> (0xlib2)
> singleton<B> (0xlib2)
> ~singleton<B> (0xlib2)
> ~singleton<A> (0xlib2)
> ~singleton<A> (0xlib1)
> ~singleton<B> (0xlib1)
> Note the switched order of the lib1 destruction. You can verify this
> yourself with #111 or #128. The problem arises because singleton<B>
> accesses singleton<A> in both its ctor and dtor but that has been
> destroyed and due to a) above this is not detected.
> We CAN try to find the reason for the mixup, OR we can rely on the
> public interface of singleton and detect it and handle it gracefully.
> The former is VERY hard, the latter is easy and actually it *is
> currently being done*!!! See
> All that is missing to avoid the crash is the fix for `is_destroyed`
I am the Robert who posts the static int counting via "printf" debugging
output on Windows. Please do not confuse my first name with Mr. Ramey.
I am not him.
FWIW, the ongoing outstanding issues within Serialization, and how the
maintainer responds to them, has caused zero use of Boost.Serialization,
within the professional development team I am part of. In fact,
Boost.Beast is the only one in use.
I hope all of Alexander Grund's PRs are added/merged. If I have the
time available, I will test his PRs on the 1.68 Serialization on
Windows, one executable calling/using one or more DLLs, containing the
Serialization and its multiple Singletons.
At least, I believe I can obtain PR changes at any time. Please tell me
if I misunderstand how github works obtaining a PR.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk