coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
read x <&${COPROC[0]}
----
The corpoc command executes a shell command in a forked shell without
waiting for it. Stdin and stdout of the coprocess are connected to pipes whose file descriptors are available as member 0 and 1 of an array, by default named COPROC.
The command used here acquires an exclusive lock on the file passed as argument to -w and then execs another command (which inherits the
lock). In this case, this other command writes a \n terminated string to
its stdout and then reads from its stdin until an EOF is encountered
which causes it to terminate, implicitly releasing the lock.
The parent shell will remained blocked in the read until it has read the
line written by the lock-keeper command. This means execution of the
main script will be paused until the lock could be acquired. The two
lines above are part of a shell function defined as ()-delimited
block. The function will thus run in a forked subshell. Upon return of
the function, the subhshell will exit which causes the stdin descriptor
of the locking coprocess to be closed, ultimatively leading to release
of the lock.
Comments, opinions or alternate suggestions, especially something which
would work with a stock /bin/sh very much appreciated.
On 2021-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
read x <&${COPROC[0]}
----
The corpoc command executes a shell command in a forked shell without
waiting for it. Stdin and stdout of the coprocess are connected to pipes
whose file descriptors are available as member 0 and 1 of an array, by
default named COPROC.
The command used here acquires an exclusive lock on the file passed as
argument to -w and then execs another command (which inherits the
lock). In this case, this other command writes a \n terminated string to
its stdout and then reads from its stdin until an EOF is encountered
which causes it to terminate, implicitly releasing the lock.
The parent shell will remained blocked in the read until it has read the
line written by the lock-keeper command. This means execution of the
main script will be paused until the lock could be acquired. The two
lines above are part of a shell function defined as ()-delimited
block. The function will thus run in a forked subshell. Upon return of
the function, the subhshell will exit which causes the stdin descriptor
of the locking coprocess to be closed, ultimatively leading to release
of the lock.
Comments, opinions or alternate suggestions, especially something which
would work with a stock /bin/sh very much appreciated.
u don;t wanna wait but you use *lock* :P
Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:Why do you need a lock? It is only need when other processes are not
On 2021-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
read x <&${COPROC[0]}
----
The corpoc command executes a shell command in a forked shell without
waiting for it. Stdin and stdout of the coprocess are connected to pipes >>> whose file descriptors are available as member 0 and 1 of an array, by
default named COPROC.
The command used here acquires an exclusive lock on the file passed as
argument to -w and then execs another command (which inherits the
lock). In this case, this other command writes a \n terminated string to >>> its stdout and then reads from its stdin until an EOF is encountered
which causes it to terminate, implicitly releasing the lock.
The parent shell will remained blocked in the read until it has read the >>> line written by the lock-keeper command. This means execution of the
main script will be paused until the lock could be acquired. The two
lines above are part of a shell function defined as ()-delimited
block. The function will thus run in a forked subshell. Upon return of
the function, the subhshell will exit which causes the stdin descriptor
of the locking coprocess to be closed, ultimatively leading to release
of the lock.
Comments, opinions or alternate suggestions, especially something which
would work with a stock /bin/sh very much appreciated.
u don;t wanna wait but you use *lock* :P
u assumption wrong :-) --- the point of this exercise is obviously to ensure that the shell waits until the lock is free (ie, not used by the
possibly concurrently running other process also manipulating the same, shared resources).
On 2021-10-11, Rainer Weikusat <rweikusat@talktalk.net> wrote:
Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
On 2021-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
read x <&${COPROC[0]}
----
Why do you need a lock? It is only need when other processes are notu don;t wanna wait but you use *lock* :P
u assumption wrong :-) --- the point of this exercise is obviously to ensure >> that the shell waits until the lock is free (ie, not used by the
possibly concurrently running other process also manipulating the same,
shared resources).
under you control?
On 2021-10-12, Rainer Weikusat <rweikusat@talktalk.net> wrote:
Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:What's problem to run them sequentually? AS if you don't have two
On 2021-10-11, Rainer Weikusat <rweikusat@talktalk.net> wrote:
Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
On 2021-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
read x <&${COPROC[0]}
----
[...]
Why do you need a lock? It is only need when other processes are notu don;t wanna wait but you use *lock* :P
u assumption wrong :-) --- the point of this exercise is obviously to ensure
that the shell waits until the lock is free (ie, not used by the
possibly concurrently running other process also manipulating the same, >>>> shared resources).
under you control?
Non-atomic modification of some set of files by two possibly
concurrently running processes.
disks?
Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:What's problem to run them sequentually? AS if you don't have two
On 2021-10-11, Rainer Weikusat <rweikusat@talktalk.net> wrote:
Branimir Maksimovic <branimir.maksimovic@icloud.com> writes:
On 2021-10-10, Rainer Weikusat <rweikusat@talktalk.net> wrote:
coproc lock -g surictrl -m 0660 -w $SURI_LOCK lock-keeper
read x <&${COPROC[0]}
----
[...]
Why do you need a lock? It is only need when other processes are notu don;t wanna wait but you use *lock* :P
u assumption wrong :-) --- the point of this exercise is obviously to ensure
that the shell waits until the lock is free (ie, not used by the
possibly concurrently running other process also manipulating the same,
shared resources).
under you control?
Non-atomic modification of some set of files by two possibly
concurrently running processes.
What's problem to run them sequentually? AS if you don't have twoWhy do you need a lock? It is only need when other processes are not
u assumption wrong :-) --- the point of this exercise is obviously to ensure
that the shell waits until the lock is free (ie, not used by the
possibly concurrently running other process also manipulating the same, >>>>> shared resources).
under you control?
Non-atomic modification of some set of files by two possibly
concurrently running processes.
disks?
They are being forced to run sequentially if both of them attempt to
modify the same set of files at the same time.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 72:43:06 |
| Calls: | 6,657 |
| Calls today: | 3 |
| Files: | 12,203 |
| Messages: | 5,332,378 |
| Posted today: | 1 |