Comment by CyberDildonics
3 hours ago
I was excusing the difference in overhead caused by making the lock more flexible
What are the two functions you're comparing and what is the actual difference in overhead that you're talking about?
a lock that can be shared between processes versus a lock that can't be.
This is a dramatic black and white difference, these would be used for two different things. In that case it's apple and oranges, one would be for interprocess communication and one wouldn't.
the difference between those two lock styles shouldn't be more than about a microsecond,
What are you basing this on? Do you have an examples or benchmarks of the actual calls and their timings?
fine for a lock that's only used 100 times a second.
Again, latency isn't about how many times something is called per second. That would matter for throughput.
> What are the two functions you're comparing
Go ask this comment, because I'm continuing their comparison: https://news.ycombinator.com/item?id=48125795
> In that case it's apple and oranges, one would be for interprocess communication and one wouldn't.
The whole point of the complaint was wtallis claiming the inter-process-capable lock was being used for locks that don't need it! That's the foundation of this conversation!
> What are you basing this on?
Basic coding knowledge and an assumption of competency. There's no good reason for it to slow down more than that when it's used the same way. If you have a reason go ahead and tell me.
> Again, latency isn't about how many times something is called per second. That would matter for throughput.
I addressed both.
The extra latency for using an overly capable lock should be negligible. That's not the problem anyone is worried about.