UniVerse provides a socket API in Basic, you can use the socket api to implement a queue, the biggest problem would be handling any timeouts and handshakes etc. I have already written one for UniVerse. I also wrote a program using the U2 Socket API to share information between UniVerse and UniData before. From experience the timeouts and working out any handshaking between the processes will require a bit of forethought and work.

If this was UniData (or UniVerse 12) the easiest way would to be use the internal record locking queues. Using READU and WRITE to use a known record between them as the locking system in UniData (and UV 12) uses a queue anyway. Process One has the lock, If process two can't get the lock  the request is put on the queue in shared memory and goes to sleep. When process one releases the lock the lock manager sends a wake up message to the first process in the queue. Sadly this won't work for you before UV 12 as the pre 12 locking and wait strategry is not an ordley queue.

I am sure if you googled for a python solution for this you would probally find one.

I use sockets in UniData.  Works great.  I have a server side and a client side.  And these are on different servers.

I use something like READU but one of the 64 synchronization locks is called LOCK.

Posted: 02-17-2023 12:02

Inter-process Communications on UV is possible, but not straight forward.

The absence of easy-to-use IPC functions in BASIC is - in my view - an opportunity missed.

The SOCKETS api can fulfull this functionality, but comes at the cost of turning your phantoms into iPHANTOMS, which use a license.

On Windows there are GCI functions for interacting with Pipes. On Unix it is possible to create a unix named pipe using unix commands.

Pipes can be used with OPENSEQ, READSEQ & WRITESEQ to interact (something we do) between running processes. You do need to invent your own protocol for welcome handshakes and data exchanges.

The use of "drop files" does also work. If you only have the 2 processes then the use of BASIC execution locks allows your processes to semaphore if they are busy or if there is work to pick up.

We have extended UniVerse with some GCI routines that enable System-V message queues for fast IPC messaging, with the ability to have a unique Queue (Key) for each application.

It enables multiple readers as well as multiple writers, monitoring the queue utilisation to scale out worker processes when the need arises.

We sometimes write a request to a UniVerse file so we do not lose the request and then write the Item ID on to a specific message queue by application, this way we keep the size of the message to the minimum, when we have thousands of interactive users firing messages there is a higher chance of this!

It also allows for multiple methods of retrieving messages from the queue which can be used to prioritise messages, retrieve a specific message type or just FIFO