Re: [PATCH] liveupdate: use scoped_guard for mutex in session operations

On Fri, Aug 14, 2026 at 04:10:34PM +0200, Pratyush Yadav wrote:
> On Fri, Aug 14 2026, Chenghao Duan wrote:
> 
> > Replace manually paired mutex_lock/unlock with scoped_guard to align
> > with the coding style of the rest of the codebase and simplify locking
> > paths.
> 
> No. This is done explicitly because we don't want to mix gotos with the
> automatic cleanup-style locking. I don't think we should change this.
> 

Thank you for the clarification. I understand your concern about mixing
`goto`-based error handling with automatic cleanup-style locking.

I was wondering if these particular cases might still be suitable for
using `scoped_guard()`. The patch only changes two manually paired mutex
lock/unlock instances, and in both cases, the guard scope is limited to
the operation that requires the mutex. The lock is released before the
subsequent error-handling logic is executed, so the `goto` paths do not
cross the scope of the guard.

We could also use an explicit `scoped_guard { ... }` scope to make the
lifetime of the guard more obvious and easier to review.

Of course, I may be missing some broader considerations. If there are
other reasons why these cases should retain the explicit lock/unlock
pattern, I would be happy to follow your guidance.

Regards,
Chenghao

> [...]
> 
> -- 
> Regards,
> Pratyush Yadav