Lars Fosdal

Depends on the dictionary, I guess. Race conditions rarely flag as errors, but cause inconsistent or erratic data, possibly leading to wrongful processing later on. In this case, at least one of the four parties would be denied access (due to exclusive write lock and - depending on the programmmer - exclusive read) to the file and hence should have/raise awareness of a problem. But, whatever.

It turns NumLock off/on/off (or on/off/on) within less than 30 ms every 60 seconds, so I don't think it will bother you much.

Our laptops are under company governance, so we can't prevent the session from locking as it is dictated by the policies. In addition, the idle time is really short. So - we wrote LockBlock which basically simulates toggling the numlock every 60 seconds. That prevented the auto locking, but it also prevented the screensaver from kicking in when the dektkop was locked, so I added handling of lock/unlock to disable the fake keystrokes when it was locked. Super simple UI: 60 second interval, starting at 8 in the morning, lasting for 8 hours - with an add an extra hour button for off work hours lock blocking. Project source attached. LockBlock.zip

I'd call that a concurrency issue, rather than a race condition? SharedFileName := '%temp%\MyFileName.ext.' + GetCurrentProcessId.ToString;

If you don't document it - how do you expect to maintain backward compatibility? My code relies on REST.Json - ObjectInstance := TJson.JsonToObject<T>(aJsonString) ; - aJsonString := TJson.ObjectToJsonString(ObjectInstance, [joIgnoreEmptyStrings, joIgnoreEmptyArrays, joDateIsUTC, joDateFormatISO8601]); - TJSONInterceptor / JsonReflectAttribute for instructing the converter to drop TDateTime properties that have 0 as value. What are the equivalents in System.Json ?

I wish the various Json classes were better documented. http://docwiki.embarcadero.com/Libraries/Rio/en/REST.JsonReflect is particularly poorly documented with regards to marshalling, interceptors and converters. I have long been wondering if the TJson.JsonToObject<T>(aJsonString) can be made to handle mixed type arrays {"list": [5, "text", {"prop": "value"}]} by injecting converters, but it seems impossible - but then again - the above mentioned tools are undocumented.

What about a memory mapped file? An idealist kind of solution could perhaps be a message queue system like f.x. RabbitMQ (https://www.rabbitmq.com/)

Also, https://github.com/tananaev/rootless-logcat Same caveat.

https://bitbucket.org/mlopatkin/android-log-viewer/src/default/ Caveat: I have not tried it myself

Another option would be to specify that file should be opened after creation already at the point where you decide to make the file in the first place.

Yes, that could work well, IMO.

I'd make a generic "application log" where I would log the different actions, and for each action type - offer the possible options when viewing the log. Whenever something is logged, I'd have a "New Item" counter (Think "number of unread") somewhere in the UI - f.x. on a button that opens the log. I also strongly dislike modal dialogs, but when I need that file, I do need a mechanism to find it.

As David says - if the setter and getter don't do anything but assignments, you can eliminate them. property X: Integer read pX write pX; property Y: Integer read pY write pY;

Work in progress. Looking at more retry resilience, rather than always once off. https://www.microsoftpressstore.com/store/exam-ref-70-762-developing-sql-databases-9781509304912

I use a cream colored background in the editor. I find that much calmer than looking at a black display.