Timeline for locking scripts using flock - can same file descriptor be used concurrently?
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 30 at 15:21 | comment | added | grawity | @jrw32982: Interesting, so that would mean bash does the dup2() dance even for {fd}. | |
| Oct 30 at 14:25 | comment | added | jrw32982 | This was interesting reading as I wasn't aware of the dup2 dance that occurred when a FD number was specified literally. Reading the bash manpage, I see the using the {fd} syntax, $fd will always be assigned a number >= 10 (at least for bash). | |
| Oct 27 at 13:26 | history | edited | grawity | CC BY-SA 4.0 | added 94 characters in body |
| Oct 27 at 11:34 | history | edited | grawity | CC BY-SA 4.0 | deleted 160 characters in body |
| Oct 27 at 11:11 | history | edited | grawity | CC BY-SA 4.0 | deleted 97 characters in body |
| Oct 27 at 11:02 | history | edited | grawity | CC BY-SA 4.0 | added 865 characters in body |
| Oct 27 at 10:48 | comment | added | grawity | They will always end up using different FDs. The number being different is completely irrelevant – it only represents a kernel-side object that the OS keeps track of (separately for each process). But file locks, by design, are "visible" across all file descriptors associated with the same file. (As that is their whole purpose – after all, a process doesn't really need file locks to protect against itself; it can use faster in-process methods for that. The whole point of file-level locking is for it to be visible across processes.) | |
| Oct 27 at 10:42 | history | edited | grawity | CC BY-SA 4.0 | added 2327 characters in body |
| Oct 27 at 10:42 | vote | accept | basher | ||
| Oct 27 at 10:42 | comment | added | basher | Okay, this clearly shows I don't really grok how flock really works. What role does exec {fd}>>"$LOCK" play in there, given separate instances of same script (i.e. still different processes) will possibly end up using different FDs? | |
| Oct 27 at 10:33 | comment | added | grawity | Another instance of the same script would have its own variables, as well. Even if both are running the same script file, they are still separate processes, so what one instance assigns to its fd variable has no effect on the fd variable of other scripts or instances. They both might end up having the same value there (e.g. 3 as the first unused file descriptor), but they're still distinct processes having their own memory areas and their own variables (... and their own file descriptors). | |
| Oct 27 at 10:32 | comment | added | grawity | (If you look at lsfd -Q 'FD >= 0' or at lsof or at ls -l /proc/<pid>/fd you'll usually see 3 being the first actual file or socket that the program has open. When bash is running a script, it manually moves the fd representing the script file somewhere to 255 or so.) | |
| Oct 27 at 10:31 | comment | added | grawity | The program (shell or otherwise) actually doesn't get to choose. The OS always gives you the first free FD (usually that's 3 and upwards). Whenever the program wants a specific FD (e.g. when doing 9>> in shell), it has to first take whatever FD it gets, then it needs to call dup2() to "copy" that FD to the desired number, then close() the no-longer-needed original. Most programs don't have such a specific need, so they just take the OS result and store it in a variable, e.g. int myfile = open("/etc/passwd", O_RDONLY). | |
| Oct 27 at 10:26 | comment | added | basher | exec {fd}>>"$LOCK" - what's happening here? Does the shell itself find a free FD and assign $fd var its value? Wouldn't another instance of same script cause another FD to be assigned, effectively breaking the locking? | |
| Oct 27 at 10:24 | comment | added | basher | "they only have meaning within the single process that creates them" - I'm an idiot! Of course, otherwise stdout & stderr (i.e. FD 1 & 2) would be mangled as well! Thanks! | |
| Oct 27 at 9:39 | history | answered | grawity | CC BY-SA 4.0 |