[
https://issues.apache.org/jira/browse/YUNIKORN-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109572#comment-18109572
]
Wilfred Spiegelenburg commented on YUNIKORN-3420:
-------------------------------------------------
I am not so sure that this would ever happen. Objects are only locked from
within the object, not outside.
In those cases while inside the object using {{String()}} or {{zap.Stringer()}}
on itself is not logical. The string function is highly limited as it only
provides a very limited view with some high level info.
Using {{String()}} or {{zap.Stringer()}} on the object while not locked for a
quick overview does make sense. Specially from outside the object. When inside
the object building a detailed log line is the norm.
Removing the locking adds back possible race conditions.
For the application, allocation and queue: a quick view of them when not locked
via the string function now shows enough detail to make sense if we remove the
fields that are volatile and require locking we might as well not have them.
> String() methods that take their own lock
> -----------------------------------------
>
> Key: YUNIKORN-3420
> URL: https://issues.apache.org/jira/browse/YUNIKORN-3420
> Project: Apache YuniKorn
> Issue Type: Sub-task
> Components: core - common, core - scheduler
> Reporter: Dale Richardson
> Assignee: jimmycmlin
> Priority: Minor
> Labels: pull-request-available
>
> {{TrackedResource.String}}, {{Queue.String}}, {{Allocation.String}} (through
> {{GetAllocatedResource}} / {{IsAllocated}}) and {{Application.String}}
> (through {{GetSubmissionTime}}) take the read lock of the object they print.
> {{fmt}} and {{zap}} evaluate a {{Stringer}} whenever the log line is built,
> which the type does not control; if that happens while the caller holds the
> object's write lock, the goroutine deadlocks on itself.
> No such caller was found in the current tree, so this is a trap rather than a
> bug that fires today. It is filed because a log line added under the write
> lock in future would hang silently, and because the fix is small.
> Fix: print only fields fixed at construction, or have the caller take a
> snapshot under the lock and print that. Note that {{Application}}'s
> submission time is not construction-fixed (it is reassigned on the recovery
> and placeholder paths), so it needs the snapshot treatment rather than a
> direct read.
> Marker: four {{+lockstringerignore}} sites carry this JIRA; the fix removes
> them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
