The discovery process of SHM buffers in the leecher driver is not very robust. It works in the Ubuntu but that's it. The problem is how non-standard the OS-level SHM implementations are, even inside POSIX compatible systems...
On Linux based systems the named SHMs can be discovered by listing files in /{dev,run}/shm/. This is a convention in POSIX based systems but it's not foolproof method and doesn't work always. For example, FreeBSD doesn't have such directory.
Also based on literature, MacOS might implement similar accessibility to via /dev/shm but once again not sure is it always available. On Windows, listing the named SHMs seems purely impossible. It's somehow possible by traversing through the whole process tree and parsing process memory section information.
So... a discovery procedure based on assumption that a list of SHM is available by the system might not be the best method.
An alternative method could be to store a list of SoapyShared-buffer names in a "meta/index" SHM. This list would be updated in seeder driver every time a new SHM is created or destroyed. This way the discovery procedure could just read the meta-SHM and test the each name in the list. The advantage of this approach would be that it the dependencies to underlying system/OS implementation are minimal.
More investigation and ideas required.
The discovery process of SHM buffers in the leecher driver is not very robust. It works in the Ubuntu but that's it. The problem is how non-standard the OS-level SHM implementations are, even inside POSIX compatible systems...
On Linux based systems the named SHMs can be discovered by listing files in
/{dev,run}/shm/. This is a convention in POSIX based systems but it's not foolproof method and doesn't work always. For example, FreeBSD doesn't have such directory.Also based on literature, MacOS might implement similar accessibility to via
/dev/shmbut once again not sure is it always available. On Windows, listing the named SHMs seems purely impossible. It's somehow possible by traversing through the whole process tree and parsing process memory section information.So... a discovery procedure based on assumption that a list of SHM is available by the system might not be the best method.
An alternative method could be to store a list of SoapyShared-buffer names in a "meta/index" SHM. This list would be updated in seeder driver every time a new SHM is created or destroyed. This way the discovery procedure could just read the meta-SHM and test the each name in the list. The advantage of this approach would be that it the dependencies to underlying system/OS implementation are minimal.
More investigation and ideas required.