Age | Commit message (Collapse) | Author |
|
|
|
This reverts commit e965e5edcdd9fdc8a4c68b4d50656cd4e0c53f18.
|
|
This does clutter up stderr, but only because instant.xml is arguably
saved much too often (and it's not really instant :)
|
|
|
|
Designed to allow derived classes to *save* a different value
than would be reported by ::get_value().
Specifically there so that slaved controls can save/restore
their *own* state, not the value that ::get_value() would
return.
|
|
|
|
|
|
|
|
|
|
This partially plugs a memory leak of event-loops.
|
|
|
|
|
|
|
|
Prevent double unref during when the EventLoop terminates:
deleting the ringbuffer deletes all requests, some of which may
contain stale invalidation
remove the buffer_map_lock, now that signals ref-count the IR.
|
|
|
|
|
|
at least for some versions of gcc.
|
|
|
|
|
|
This kills 2 birds with 1 stone: Removes the necessity of locks
and makes call_slot() realtime safe (req->invalidation->requests list
push_back). On object destruction, the invalidation-record (IR) itself is
invalidated.
Invalidated IRs are pushed onto a trash-pool and deleted in the event-loop
of the invalidated object (GUI thread) once all requests that reference it
have been processed.
One last detail remains: PBD::signal connect should reference the IR
and disconnect unreference it. This will guarantee that signal emission
will not reference the IR while the pool trash is dropped.
|
|
While EventLoop::invalidate_request() does invalidate request in the
request-list. It does *not* invalidate requests in the
per-thread-request-ringbuffer(s).
The invalidation record cannot be deleted in EventLoop::invalidate_request
see 6b5891a78f.
|
|
|
|
Yet another slightly overkill approach, but it /may/ explain crashes.
|
|
|
|
When do_request() destroys the receiver object, the receiver will
free the invalidation record. So the IR needs to be removed from the list
before executing the request.
Invalid read of size 8
at: AbstractUI<Gtkmm2ext::UIRequest>::handle_ui_requests() (abstract_ui.cc:242)
by: BaseUI::request_handler(Glib::IOCondition) (base_ui.cc:141)
by: sigc::bound_mem_functor1<bool, BaseUI, Glib::IOCondition>::operator()(Glib::IOCondition const&) const (mem_fun.h:2066)
by: sigc::adaptor_functor<sigc::bound_mem_functor1<bool, BaseUI, Glib::IOCondition> >::deduce_result_type<Glib::IOCondition const&, void, void, void, void, void, void>::type sigc::adaptor_functor<sigc::bound_mem_functor1<bool, BaseUI, Glib::IOCondition> >::operator()<Glib::IOCondition const&>(Glib::IOCondition const&) const (adaptor_trait.h:89)
by: sigc::internal::slot_call1<sigc::bound_mem_functor1<bool, BaseUI, Glib::IOCondition>, bool, Glib::IOCondition>::call_it(sigc::internal::slot_rep*, Glib::IOCondition const&) (slot.h:148)
by: sigc::slot1<bool, Glib::IOCondition>::operator()(Glib::IOCondition const&) const (slot.h:643)
by: cross_thread_channel_call_receive_slot(_GIOChannel*, GIOCondition, void*) (crossthread.cc:49)
by: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
by: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
by: g_main_loop_run (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.2)
by: gtk_main (in /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.31)
by: Gtkmm2ext::UI::run(Receiver&) (gtk_ui.cc:286)
by main (main.cc:408)
Addrd1b8 is 24 bytes inside a block of size 48 free'd
at: operator delete(void*) (vg_replace_malloc.c:576)
by: PBD::EventLoop::invalidate_request(void*) (event_loop.cc:98)
by: sigc::internal::trackable_callback_list::~trackable_callback_list() (in /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0.0.0)
by: sigc::trackable::notify_callbacks() (in /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0.0.0)
by: ProcessorEntry::LuaPluginDisplay::~LuaPluginDisplay() (processor_box.cc:1757)
by: ProcessorEntry::LuaPluginDisplay::~LuaPluginDisplay() (processor_box.cc:1760)
by: ProcessorEntry::~ProcessorEntry() (processor_box.cc:251)
|
|
|
|
|
|
For now: use a single lock, which should fix all related crashes.
optimize (with less contended partial locks) if this works.
|
|
|
|
|
|
Some overzealous locking to track down RequestObject related crashes.
bc0fa4d689a4 wrongly locked the current event loop's
request_invalidation_lock instead of the invalidation's list lock.
Also Abstract UI is able to delete requests concurrently with with
EventLoop invalidation.
e.g. PortManager::PortRegisteredOrUnregistered and GlobalPortMatrixWindow
so the lock needs to be exposed.
If this solves various issues, mutexes should to be consolidated
(request_buffer_map_lock + request_invalidation_lock) and be chosen
such that there is as little contention as possible.
|
|
The new specialisation for ConfigVariable<float>::set_from_string() needs to be exportable (it gets used somehow by ARDOUR::SessionConfiguration).
If adding LIBPBD_API causes a problem for gcc, we could change it to LIBPBD_TEMPLATE_MEMBER_API
|
|
(use std::strtod() in earlier versions)
|
|
|
|
The default for export-silence-threshold is -INFINITY, written
as "-inf" (by cfgtool) into system_config. Yet parsing the config using
a std::stringstream results in "0" (due to bugs in various libc++).
|
|
Just an update to slightly rotten wscripts, shouldn't be any changes during an
ardour build. Motivation being a short development cycle for working on evoral
and/or its test suite.
|
|
Fixes an issue with corrupted std::lists<> due to concurrent writes
to the invalidation list which eventually resulted in
EventLoop::invalidate_request() not invalidating requests.
Concurrency sucks rocks hard.
|
|
|
|
|
|
Simplify the #ifdef logic so it is easier to follow and add exceptions in the
future if necessary.
|
|
|
|
x-thread channel from an event loop when it is destroyed
|
|
The number of properties per node roughly corresponds to the number of members
of the class the node is representing and should be fairly low.
Use std::vector::reserve to prevent reallocation on insert for most node types,
there are exceptions like Region(~40 properties).
This seems worth it as part(maybe 1/10th of the total time) of saving a Session
is a combination of what occurs in "Create" and "Write" in this test.
Perf results before changes:
XMLTest::testPerfMediumXMLDocumentTiming
Create : Count: 10 Min: 30610 Max: 42656 Total: 376672 Avg: 37667 (37 msecs)
Write : Count: 10 Min: 42804 Max: 54277 Total: 460455 Avg: 46045 (46 msecs)
Read : Count: 10 Min: 70364 Max: 85484 Total: 750909 Avg: 75090 (75 msecs)
XMLTest::testPerfLargeXMLDocumentTiming
Create : Count: 10 Min: 164360 Max: 356995 Total: 3064482 Avg: 306448 (306 msecs)
Write : Count: 10 Min: 308655 Max: 372953 Total: 3226707 Avg: 322670 (322 msecs)
Read : Count: 10 Min: 517243 Max: 541839 Total: 5289950 Avg: 528995 (528 msecs)
Perf results after changes:
XMLTest::testPerfMediumXMLDocumentTiming
Create : Count: 10 Min: 30375 Max: 48253 Total: 431727 Avg: 43172 (43 msecs)
Write : Count: 10 Min: 42553 Max: 49163 Total: 453353 Avg: 45335 (45 msecs)
Read : Count: 10 Min: 70307 Max: 75987 Total: 734923 Avg: 73492 (73 msecs)
XMLTest::testPerfLargeXMLDocumentTiming
Create : Count: 10 Min: 154486 Max: 307856 Total: 2678989 Avg: 267898 (267 msecs)
Write : Count: 10 Min: 304273 Max: 343274 Total: 3169158 Avg: 316915 (316 msecs)
Read : Count: 10 Min: 496920 Max: 541394 Total: 5260410 Avg: 526041 (526 msecs)
|
|
It appears that there is no performance benefit from storing properties in a
map for faster lookup or it is counteracted by the penalty of storing and
maintaining the additional data structure.
Timing results before changes with an optimized build:
XMLTest::testPerfMediumXMLDocumentTiming
Create : Count: 10 Min: 41293 Max: 63746 Total: 564448 Avg: 56444 (56 msecs)
Write : Count: 10 Min: 42932 Max: 49221 Total: 453955 Avg: 45395 (45 msecs)
Read : Count: 10 Min: 80160 Max: 84678 Total: 824506 Avg: 82450 (82 msecs)
XMLTest::testPerfLargeXMLDocumentTiming
Create : Count: 10 Min: 228759 Max: 420236 Total: 3587597 Avg: 358759 (358 msecs)
Write : Count: 10 Min: 307095 Max: 348767 Total: 3205704 Avg: 320570 (320 msecs)
Read : Count: 10 Min: 572400 Max: 657219 Total: 5959630 Avg: 595963 (595 msecs)
Perf results after changes:
XMLTest::testPerfMediumXMLDocumentTiming
Create : Count: 10 Min: 30610 Max: 42656 Total: 376672 Avg: 37667 (37 msecs)
Write : Count: 10 Min: 42804 Max: 54277 Total: 460455 Avg: 46045 (46 msecs)
Read : Count: 10 Min: 70364 Max: 85484 Total: 750909 Avg: 75090 (75 msecs)
XMLTest::testPerfLargeXMLDocumentTiming
Create : Count: 10 Min: 164360 Max: 356995 Total: 3064482 Avg: 306448 (306 msecs)
Write : Count: 10 Min: 308655 Max: 372953 Total: 3226707 Avg: 322670 (322 msecs)
Read : Count: 10 Min: 517243 Max: 541839 Total: 5289950 Avg: 528995 (528 msecs)
|
|
It is slightly surprising but there seems to be little difference to
performance with these changes. Possibly a slight improvement in "Create" test
with a large xml document(~5%).
Timing results before these changes with an optimized build using new XML perf tests:
XMLTest::testPerfMediumXMLDocumentTiming
Create : Count: 10 Min: 38656 Max: 63827 Total: 571228 Avg: 57122 (57 msecs)
Write : Count: 10 Min: 43594 Max: 49279 Total: 459907 Avg: 45990 (45 msecs)
Read : Count: 10 Min: 80247 Max: 84912 Total: 827207 Avg: 82720 (82 msecs)
XMLTest::testPerfLargeXMLDocumentTiming
Create : Count: 10 Min: 230706 Max: 456054 Total: 3850998 Avg: 385099 (385 msecs)
Write : Count: 10 Min: 312322 Max: 353789 Total: 3264211 Avg: 326421 (326 msecs)
Read : Count: 10 Min: 573556 Max: 610865 Total: 5951908 Avg: 595190 (595 msecs)
Timing results after these changes:
XMLTest::testPerfMediumXMLDocumentTiming
Create : Count: 10 Min: 41293 Max: 63746 Total: 564448 Avg: 56444 (56 msecs)
Write : Count: 10 Min: 42932 Max: 49221 Total: 453955 Avg: 45395 (45 msecs)
Read : Count: 10 Min: 80160 Max: 84678 Total: 824506 Avg: 82450 (82 msecs)
XMLTest::testPerfLargeXMLDocumentTiming
Create : Count: 10 Min: 228759 Max: 420236 Total: 3587597 Avg: 358759 (358 msecs)
Write : Count: 10 Min: 307095 Max: 348767 Total: 3205704 Avg: 320570 (320 msecs)
Read : Count: 10 Min: 572400 Max: 657219 Total: 5959630 Avg: 595963 (595 msecs)
|
|
Generate, write and then read three Session like XML files to test the
performance of changes made to pbd/xml++.h API
|
|
Implemented to be able to test that when writing an XML document via XMLTree
and then reading back into another XMLTree the structure is equivalent as a
general API test of pbd/xml++.h to check for breakage when changing
implementation.
|
|
|
|
|
|
|