@MSGID: 1@dont-email.me> 7b76d6b8
@REPLY: 2@dont-email.me> 8f88b355
@REPLYADDR David Brown <david.brown@hesbynett.no>
@REPLYTO 2:5075/128 David Brown
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
1@dont-email.me> 1@dont-email.me> 1@dont-email.me>
2@dont-email.me>
@TZUTC: 0200
@PID: Mozilla/5.0 (X11; Linux x86_64; rv:60.0)
Gecko/20100101 Thunderbird/60.6.1
@TID: FIDOGATE-5.12-ge4e8b94
On 08/08/2023 17:14, pozz wrote:
> 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?
> 

Yes, exactly.

A file in Linux exists independently from filenames.  There can be many 
things pointing to a file, and the file exists until there are no more 
pointers.  Usually these "pointers" are directory entries, but they can 
also be open file descriptors (which are actually visible as pseudofiles 
in the /proc filesystem).

So when you open the "status.json" file, you get that file, and it stays 
in existence at least until the file is closed.  The new "status.tmp" is 
a different file.  The rename just makes a new pointer to the new file, 
and erases the old pointer to the old file.

> 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?
> 

Yes, as long as you hold the file descriptor open.

--- Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
 * 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