[Bug translator/26296] delay script-global locking until required

["craig at 2ndquadrant dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=26296

--- Comment #4 from craig at 2ndquadrant dot com ---
On Wed, 5 Aug 2020 at 03:59, fche at redhat dot com via Systemtap <
systemtap@sourceware.org> wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=26296
>
> --- Comment #3 from Frank Ch. Eigler <fche at redhat dot com> ---
> > Even an explicit construct that scopes locking would be handy. Borrow
> from
> > Java's "synchronized" perhaps.
>
> If one can come up with easy-to-explain, implementable, safe
> semantics, yeah perhaps!
>

I'm thinking something like this:

* Explicit locking is scoped to a block
* Locks are acquired against a named global variable
* Within a scope that uses explicit locking, ab attempt to access global
variables for which locks have not been explicitly acquired is a semantic
error
* Any exit from a block - "next", "return", throwing an exception, etc -
releases the lock at escape from the block.
* A warning will be raised during compilation if any given global is
accessed under explicit locking in one part of a script or tapset, but via
implicit probe level locking in another part.

Deadlock protection is a bit interesting. I haven't looked at how systemtap
takes care of that at the moment. If it can detect deadlock and fail
gracefully that's probably sufficient.

Of course it's all handwaving unless I have time to write it, since I don't
get to ask others to. And I'm a bit stuck in C++ error message spam in the
relatively simple patch I wrote for @enum already...

-- 
You are receiving this mail because:
You are the assignee for the bug.