in reply to Re^2: atomic tie?
in thread atomic tie?

Yes, but perl itself is fundamentally a single process. All that other stuff is to avoid the inherent lack of thread safety. I understand it was never meant to be thread safe, so don't take that as a criticism.

Replies are listed 'Best First'.
Re^4: atomic tie?
by ikegami (Patriarch) on Aug 24, 2024 at 15:26 UTC

    Yes, but perl itself is fundamentally a single process.

    What does that mean??? What does that have to do with anything???

    You said "If your getting a race condition, it's between 2 or more forked perl processes". This is clearly wrong. At so many levels.

    Even if Perl was single process and single threaded and didn't have coros and didn't have signals and didn't have async IO and ... Even if all that, a race condition is still possible. The OP is talking about a database, so there could be a race with other users of the database!

[reply]
      OP didn't give much information. If it's a single perl process then the race condition would be in the database. If he is using fork (e.g.,) and making the DB calls inside of one of the 2+ perl processes this implies, then he could have a race condition. No? Can't tell unless we get more information.
[reply]
[d/l]
[select]

        then the race condition would be in the database.

        A database alone is not a system that ends up in a race condition. You could have a race would be between the programs/processes/threads using a database, for example. The system suffering from the race condition would entail not the just the database, but those programs/processes/threads too.

        then he could have a race condition.

        I didn't say that forking couldn't lead to a race condition.

        Can't tell unless we get more information.

        I only said your claim that race conditions necessarily come from forking a Perl process was false. No extra information is needed for this.

[reply]

In Section Seekers of Perl Wisdom