mirror of
https://review.haiku-os.org/haiku
synced 2025-01-21 22:04:49 +01:00
81acff62c6
Previously, since we passed B_RELATIVE_TIMEOUT unconditionally, a timeout of 0 would mean that it would return as soon as there was CPU time available (so, usually, instantly.) This usually was not a "problem" in that it caused broken behavior, but it would result in exceptionally high CPU usage. At first I implemented this correctly (i.e. a timeout of 0 will block until explicitly woken up) but then discovered that our implementation of these functions creates subtle race conditions compared to their FreeBSD counterparts, and so to avoid deadlocks, a timeout of 1 second is imposed. For situations where there are deadlocks due to race conditions, this will make them painfully obvious (e.g. all network transfers stalling for a second every 2-3 seconds or so.)