@MSGID: 2@dont-email.me> 8f88b355
@REPLY: 1@dont-email.me> a619a9aa
@REPLYADDR pozz <pozzugno@gmail.com>
@REPLYTO 2:5075/128 pozz
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 2@dont-email.me>
@RFC-References: 1@dont-email.me>
1@dont-email.me> 1@dont-email.me> 1@dont-email.me>
@TZUTC: 0200
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.14.0
@TID: FIDOGATE-5.12-ge4e8b94
Il 08/08/2023 16:31, David Brown ha scritto:
> On 08/08/2023 14:59, pozz wrote:
>> Il 08/08/2023 12:27, David Brown ha scritto:
>>> On 07/08/2023 23:28, pozz wrote:
>> [...]
>>>> What do you suggest?
>>>>
>>>> PS: In the past I read only a few posts regarding Linux development, 
>>>> even if it`s for embedded devices. However I don`t know how to ask 
>>>> questions related to linux development, I noticed Usenet linux 
>>>> groups are somewhat dead.
>>>
>>> I don`t know what kind of information you are needing, but an easy 
>>> option might be to have the python service regularly write out a json 
>>> format file with the current status or other information.  The web 
>>> app can have Javascript that regularly reads that file and handles it 
>>> on the user`s web browser.  And if you want to go the other way, your 
>>> Python code can use "inotify" waits to see file writes from the web 
>>> server.
>>
>> Sincerely I don`t like your solution. First of all, you are writing 
>> regularly on a normal file in the filesystem. Ok, maybe I can use a 
>> tmpfs filesystem in RAM.
>>
> 
> That would be the normal choice, yes.
> 
>> Another issue I see is synchronization. Without a sync mechanism, the 
>> reader could read bad data, because the writer is writing to it.
>>
> 
> You typically handle this by writing to "status.tmp", then renaming 
> (moving) it to "status.json", or whatever names you are using.  Renaming 
> a file like this is guaranteed atomic on Linux - anything attempting to 
> open a handle to "status.json" will either get the old file (which is 
> kept alive while the file descriptor is open) or the new file.  This is 
> not the first situation in which people wanted to avoid reading 
> half-written files!

Good thing to know.

Just to better understand what happens. If reader opens status.json just 
before the writer rename status.tmp to status.json, we will have a 
process (the reader) that reads from the old version of "status.json" 
instead of the new version that is really on the filesystem?

Consider that the reader could keep open the old status.json for a long 
time. Does the OS guarantee that old data (maybe 1GB) can be read even 
if a new file with new data is available?

 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.14.0
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441