Grab lock before invoking hook

[duke8253]

Need to grab the lock such that APIHook::invoke can do its thing.
Requires #5857.

[duke8253]

[approve ci autest]

[masaori335]

Do you mean there is a case of curHook->m_cont->mutex is nullptr by "Requires #5857".
In that case, does this SCOPED_MUTEX_LOCK make sense?

[SolidWallOfCode]

No, but overall the code is simplified by putting the check in SCOPED_MUTEX_LOCK. Otherwise every place that invokes the continuation would have to have the same cut and pasted logic. This is the reason that was moved in to MUTEX_TRY_LOCK.

[duke8253]

Yeah, I meant it needs the null checking , since some times the mutex could be pointing to nothing

[maskit]

Less dup code is fine but failing silently doesn’t sounds great.

[duke8253]

I don't think it counts as failing. If a mutex is provided, it locks it just the same as before, if a nullptr is provided nothing happens.

[SolidWallOfCode]

That doesn't help - this macro isn't accessible from the C API and so another macro doesn't provide the opportunity to specify "no lock needed". Passing nullptr isn't a mistake, even in your example it's done quite deliberately during creation of the continuation.

Perhaps you could be more explicit about an alternative that would allow having nullptr for a continuation mutex that does not result in an assertion based crash?

[bryancall]

Looking at the use of SCOPED_MUTEX_LOCK in most cases we don't do a nullptr check and require that there is a mutex. This would change the semantics in those cases and if some part of the code accidentally sets the mutex to null (not uncommon that memory is accentually written to) we would then not be holding a mutex.

The issue that @maskit has should have been addressed in #5857 before approving and merging the change.

[SolidWallOfCode]

Does that imply reverting the change to MutexTryLock, which has had the same nullptr exception since February? Or should these two macros / classes have this fundamental difference?

[SolidWallOfCode]

If the nullptr check is moved to be only in to the macro, the class constructor will crash on a nullptr mutex.

I would recommend WEAK_MUTEX_TRY_LOCK and WEAK_SCOPED_MUTEX_LOCK for the nullptr accepting versions. Then the current ones do an assert and invoke the WEAK version.

[bryancall]

Yes, that would mean changing MutexTryLock too. You could add a ink_assert() or ink_release_assert() for the mutex, but crashing on dereferencing a null pointer is easy to track down and I wouldn't bother.

[duke8253]

Closing this because new PR #5879 deals with the problems.