| Ticket UUID: | 4f322b9d2112772a4a9599611def6e651f8e5198 | ||
| Title: | Impossibility to create an unique path in Tcl (e. g. using file mkdir) | ||
| Type: | RFE | Created on: | 2018-07-02 12:12:33 |
| Submitter: | sebres | Assigned to: | nobody |
| Subsystem: | 16. Commands A-H | Severity: | Minor |
| Priority: | 5 Medium | Last modified: | 2018-10-10 22:41:54 |
| Status: | Pending | Closed by: | nobody |
| Resolution: | Fixed | Closed on: | |
| Version: | >= 8.5 | ||
| Description: | ||||
|
If working multi-threaded (or multi-processed in cluster-system on share) with some global directory to create some system-wide unique sub-path using some pseudo-unique name generation algorithm (also UUID), to avoid retrieving of the same folder for two workers, one can do the things like this:
But it's affected by the race condition (firstly not exists for both workers, then one creates sub-path, another returns with no error in `file mkdir` on same existing path), if some_uuid_algo cannot guarantee a system-wide unique path. So the creation of a safe construct for that is impossible in Tcl currently. Suggestion: Currently `file mkdir` returns no result at all. This is race condition safe.
The only one backwards-incompatibility in this case would be usage like this:
| ||||
| User Comments: | ||||
sebres added on 2018-07-02 15:05:03:
Implemented in branch rfe-4f322b9d21 for >= 8.5th. Although I think, it could be accepted as it's, adding a short changelog entry with small incompatibility note like: command `file mkdir` returns integer now vs. nothing previously... But TCT should decide about it. So pending as implemented. aspect added on 2018-07-12 09:43:10:
I approve of this change. Can we afford to break code that relies on the empty result from [file mkdir]? See also https://core.tcl.tk/tips/doc/trunk/tip/431.md and the ensuing wiki discussion at https://wiki.tcl.tk/40609 https://core.tcl.tk/tcl/info/270f78ca95b642fb is also relevant. sebres added on 2018-10-10 22:41:54:
So [270f78ca95b642fb] is definitely closed, well it is time to "close" another race-condition (this RFE fixed). | ||||
