Hi, all!!

I'm trying to share a variable between two applications. The first one gathers information and fills a variable of some_struct type. I want my second application be able to read that.

Can anyone help me?

Thanks in advance.

What you are looking for is IPC or inter-process communication. Most modern desktop/server operating systems use processors that virtualize addresses and map physical memory to virtual memory addresses as needed. Each process is then created in its own virtual memory address range. A process can not access memory addresses of other processes.

In order to share memory or data between two separate processes, one must use some form of IPC. The section of the book, Advanced Linux Programming, which is available for free downloading on the 'net, that covers IPC is chapter 5.

There are a few different methods. You'll probably want to explore them all, but the quickest and easiest "producer/consumer" variety is the named pipe.

Note that all of the examples in ALP are C-centric.


MxB

Or you can write the value to a file and the second process can read the file. Of course timing is an issue.

Process 1:
Does the file exist?
Yes -- wait. Process 2 hasn't read it yet.
No --- write the file.

Process 2:
Does the file exist?
Yes -- read and delete the file.
No --- wait, Process 1 does not have the value yet.

__________________

The 3 Laws of the Procrastination Society:
1) Never do today that which can be put off until tomorrow
2) Tomorrow never comes

In short, the "existence" of the file in the file system is not any kind of assurance that the producer has completed writing and therefore, once read, is "ready" for deletion by the consumer because the producer may still be waiting to write more data to the "existing" file that the consumer is now trying to delete. If that is "timing is an issue," then the issue is overwhelmingly against the programmer.

This "solution" is no solution at all, nor should it be considered by anyone as an option that is even reasonably viable. We can not possibly know when the OS has interrupted the writing process (producer) and context switched to the reading process (consumer) and whether or not that the context switch has interrupted the write (or not). In fact, we actually know nothing about the producer and we (as this architecture suggests) suppose that the existence of a file means that it is ready to be read. If the producer creates the file with the intention of writing, but for whatever reason, the write is delayed as a result of the data acquisition or perhaps a context switch, the consumer is going to attempt to read nothing from an empty file and then delete it while the producer would otherwise not know that the file is now gone. At best, we can hope that the OS decided that the file is already open and that an existing file handle was obtained by the producer and therefore does not delete the file when the consumer asks otherwise.

If we can determine anything at all from this suggestion, we can say for sure that we absolutely do not know at all if anything good can possibly come from such an implementation. If it works at all, it is a miracle of cosmic proportions and we should appreciate it from a perspective solely based on the statistics involved.

If WaltP has an example of working code to support this kind of implementation on Linux or otherwise, I'd like to see it. I don't see how the risk of the "timing issue" is mitigated by this kind of "solution." And, I don't see how the basic logic steps described above could possibly be made to work on any real world system...not to mention any of the other real world issues such as a process being killed or simply dying or otherwise exiting/going away. What would happen if the producer died in the middle of a write and the consumer found the file existed, read the partial contents and then decided to delete it? What would happen if the consumer decided that the read was partial and waited until the consumer restarted and somehow wrote some new data? Would a partial write still be in the file?

I don't see any reasonable situation where this architecture suggestion would be appropriate. Maybe I don't understand its implementation or there are some details left out of the above logic that would somehow make it work?

Does "of course timing is an issue" mean that the issue is one that can reasonably be solved using this architecture? I don't see how it can be made to reliably work.


MxB

Hmmm, OK. The file cannot be 'ready' until the file is closed. If the file is closed, the data has been 'written'. As per the OP's requirements, I'm trying to share a variable between two applications.. Yes, assumption on my part, a variable might be a 25K string, but I made the assumption it's most likely no more that 4 bytes.

I'm not going to pick his tirade apart point by point, esp since the 'edge' problems MxB quote also impact any attempt as interprocess communication, and any programmer worth his salt won't get into half the other problems envisioned by my esteemed colleague.

I gave a possible idea, not a complete solution. Of course it must be fleshed out. I do not give complete solutions as my colleague tends to do, but I will help the OP flesh it out if need be.

__________________

The 3 Laws of the Procrastination Society:
1) Never do today that which can be put off until tomorrow
2) Tomorrow never comes

Thanks, guys for your answers.

My idea was to create a shared struct in the first process that contains a pointer to a function of known type and, if that variable is assigned, execute it when some information is changed. If not, continue gather information and fill MySQL table.

The second process assigns to that pointer its function. If the first process does not exist, it throws NO_FIRST_PROCESS exception and terminates. So, even if one could think a reliable algorithm for sharing via file, it is not approptiate in my case.


Mexican_Bob, thank you once more for your detailed answer.

Existence of a file can be determined whether it is opened or closed. The logic--as presented--wants the existence of the file before proceeding. We can not possibly know if data has been written and that all writes are completed by the mere existence of the file.

I'll try to tone down my remarks so that they are not perceived as being a "tirade" by you and perhaps others. Perhaps you can walk us through your logic using a bit of code that expresses your logic?

A "variable" may be a structure of both POD and "complex" data, too. Even if the size of the write is only 4 bytes, do we gain any form of assurance by this fact or does it lurk as a time bomb waiting to explode any time we encounter a not-so fringe "edge" case?


Mxb

As I said, I did not give a complete solution. The 'holes' you see are fairly easily plugged with knowledge of file I/O.

The file is created as non-sharable in the first process. The data is immediately written to the file, and the file is closed. No data collection, no 'other processing'. You can even lock the process as non-interruptible given the right system and the proper knowledge of system calls.

On the receiver side, if you cannot open a file, it is not ready to be read. The error may be "File does not exist" - self evident. If the file exists the error may be "File locked by another process" - obviously the file is not ready to be read. In some systems, you can open a file for read even though the file is open for write elsewhere. Therefore you open the file for read-write. Only access is if no other process has the file opened. Hence, if the file exists, is opened, and readable, it is ready to be read.

I have seen this technique work. I know it's not perfect, but in many cases it will suffice. In production code I wouldn't use it. But for concept testing, probably.

With the new information vahagn_iv added so we actually understand his project, shared memory is the way to go. But again you have the timing issue. What if process 1 is in the middle of writing to the memory when process 2 decides to read it? A lockout feature must be designed to alleviate this access crash.

Thank you.

__________________

The 3 Laws of the Procrastination Society:
1) Never do today that which can be put off until tomorrow
2) Tomorrow never comes