Re: New Feature Request

[Ángel]

On 2020-12-27 at 13:30 -0500, Saint Michael wrote:
> Yes, superglobal is great.
> Example, from the manual:
> " Shared Memory
> Shared memory allows one or more processes to communicate via memory
> that appears in all of their virtual address spaces. The pages of the
> virtual memory is referenced by page table entries in each of the
> sharing processes' page tables. It does not have to be at the same
> address in all of the processes' virtual memory. As with all System V
> IPC objects, access to shared memory areas is controlled via keys and
> access rights checking.
> Once the memory is being shared, there are no checks on how the
> processes are using it. They must rely on other mechanisms, for
> example System V semaphores, to synchronize access to the memory."
> 
> We could allow only strings or more complex objects, but using bash-
> language only, an internal mechanism,
> 
> Is it doable?

Yes. In fact, you can already do that using an interface exactly
identical to file operations:

# Store a string in shared memory with key 'foo'
echo "Hello world" > foo

# Read value of key foo
var="$(<foo)"


You only need to use that on a tmpfs filesystem, and it will be stored
in memory. Or, if you wanted to persist your shared memory between
reboots, or between machines, you could place them instead on a local
or networked filesystem.

For a tmpfs, the hit would be negligible. In fact, you can find "files"
created by System V ipc on the tmpfs directory /dev/shm

Semaphores would be a bit harder. Support for SysV semaphores could be
added in ipcs(1). Note however, that it's already possible to create
semaphores based on flock(1), even though it requires some more code
than a primitive that already offered a semaphore, but that's not
unlike working from futex(7).

Best regards and Happy 2021