Errno::EACCES: Permission denied @ fptr_finalize (in Windows) about futex

[tsvayer]

@dapi I understand you reasoning and mostly agree.
But to discuss anything concrete we need to create a well defined context. I am not aware of any usage of Futex and have no idea what Zold is. All I know is the list of features/requirements listed by an original author in Readme file of this repository and that is a context for me. If we are to question any specific usage of locking in general, then lets find a better context for it, maybe another issue under Zold repository.
As @yegor256 clearly stated here he has no plans to change feature list.

[dapi]

Put it here: https://stackoverflow.com/questions/1632470/accessing-a-single-file-with-multiple-threads

[dapi]

@yegor256 did you see this gem? https://github.com/sheerun/filelock

[yegor256]

@dapi yes, it's a good gem, but we need more logging. That gem won't report the cause of deadlock correctly. We need to know what's going on and why.

[yegor256]

@tsvayer maybe you can help us here?

[dapi]

@yegor256 better way is to design application without mutex. Spend time to think how to do it rather than make you own bicycle.

For example Zoldy has stores that does not require a mutex at all - https://github.com/dapi/zoldy/tree/master/app/stores

[yegor256]

@dapi are you sure they are thread safe?

[dapi]

Of course.

Give me described (human readable) usage example of mutex/futex in Zold and I show solution without it.

[yegor256]

@dapi just a list of remote nodes, as a simple file. How can you make it thread-safe without Mutex?

[dapi]

One node - one file/directory by specific path. List of these directories is list of nodes.

[dapi]

Create a directory when you met a node, save to it standalone file with score and errors log and so on.

[yegor256]

@dapi nice :) But then you need to update the information about this node. Say, you want to change the number of errors in the node. You will have to update the content of the file. How do you do that without Mutex?

[dapi]

@yegor256 replied above )

score rewritten every time it comes
.error creates every time it comes and purges sometimes

[dapi]

in any cases mutex is too common/standard/old method to do it yourself. It is better to find existing solutions and implementations

[yegor256]

@dapi well, yes, this is an option) You simply shift the synchronization problem to the file system. It will synchronize all operations for you. This will work, of course, but not always. What if you do need a file to be shared by multiple threads (like a wallet file). How will you synchronize access to it without Mutex?

[tsvayer]

@dapi, @yegor256

https://github.com/sheerun/filelock provides ONLY exclusive locking. Futex provides both exclusive AND shared locking. This combination is where it becomes "complicated".
Additionally here is what it says about cleaning garbage:

How it's different from cleverua-lockfile gem?

Cleverua removes lockfile after unlocking it. Thas has been proven fatal both in my tests and in filelocking advices from the Internet. You could try find a way to remove lock file without breaking Filelock tests. I will be glad to accept such pull-request.

and cleverua-lockfile itself provides very simplistic exclusive locking, exactly what @tank-bohr shows in his comment. And this cleaning is where it becomes really complicated.

[dapi]

@yegor256

You simply shift the synchronization problem to the file system.

Yeah. We use filesystem in any cases.

What if you do need a file to be shared by multiple threads (like a wallet file). How will you synchronize access to it without Mutex?

Tell real example scenario, please.

Here https://github.com/dapi/zoldy application stores wallet's copies in separate directories and create a symlink to best one. The name of a directory is a SHA digest of wallet's body. Every copy contains

[dapi]

@tsvayer yeah.

I think today it is very suspiciously to make a custom mutex library.

I believe if we need to make our own mutex library than we do something wrong. Using mutex is critical to performance and it requires major attention. Probably we need to rethink application's design. There are many other solutions (redis as example).

As I see futex was born for Zold.

But Zold is not about mutexes. It is about safe micropayments and zold's developers must think about safety and payments and must not spent time to develop custom solution for typical situations.

Decision about custom mutexes usage could be delayed and this is why it must be delayed.

[tank-bohr]

🍿