Yesterday I've committed a patch that addresses some issues with locking
around callbacks and visitors. Currently it's done like this:
- __libdw_visit_scopes doesn't do any lock handling itself. It needs
at least a read lock, but the caller needs to use the right locking
level with respect to the visitor that is called. It's assumed that
previsit and postvisit may relock.
- When handing the control over to external callback (for example
dwarf_func_inline_instances), the visitor may need to unlock, so that
the callback can use official (locking) elfutils API, and later lock
again. My plan is to use this unlock-callback-relock approach in all
places where callbacks are used.
- The lock that is taken after callback returns is rdlock. That makes
sense, because write lock is typically needed only to init caches and
similar, and that is relatively infrequent operation. However that also
means that the lock level can actually be downgraded. When taking
wrlock in advance ("we are going to need wrlock anyway, so take it right
away"), the care has to be taken not to call functions that can
downgrade the lock this way.
- I've been rich with comments that reason why we don't mind that this
or that function may relock. This is to mark calls where the relocking
analysis has been done. These marks, however, may become invalid as the
code evolves. I don't really know what to do about that, apart from
stripping these marks when the branch stabilizes, and insisting that any
future developers analyse the code again to see if relocking takes
place, and is a problem with respect to their patch.
 The "let's not work on thread safety right now" mail came in the
mean time, so actually that /was/ my plan. I'll try to wrap up callback
work before the end of the week. Failing that, I'll use the above notes
to bootstrap myself once I get back to work on this.
Show replies by date
Thanks for the update, Petr. I'd need to review your code before
commenting on your approach in any useful detail. Since this is moving to
the back burner and all my front burners are thoroughly on fire, let's
table all this thinking until later. Thankfully everything we've said now
is in a public archive in case someone else wants to pick it up and restart
the discussion before we get back to it.