On 1/18/21 4:03 PM, Derek Lesho wrote:
On 1/17/21 7:42 PM, Zebediah Figura wrote:
According to my reasoning, in order to really have PulseEvent work right, we need explicit scheduler support. That does bring up the option of having a "scheduler", i.e. managing wait-queues, in user space. Unfortunately this still doesn't help with the shared memory problem—in fact, now it's worse, because processes can die while holding locks that the scheduler needs. This means that wineserver itself—the "kernel" of Wine applications—can be broken by a misbehaving process, which is absolutely unacceptable for Wine.
Forgive me if I'm missing something obvious, but couldn't wineserver wait on a thread's destruction and run a fallback cleanup routine, if a thread terminated chaotically?
It would help, but not very much in the long run. The scheduling information would still be left in an inconsistent state, and this doesn't address the problems inherent to use of shared memory in the first place. It also doesn't help the case where a thread is suspended, or live- or dead-locks.
In regards to the problem of bugs having worse effects and being easier to happen here, isn't the surface area of these APIs small enough to keep a close eye on in maintenance? I guess my question is, do you think a stable solution is possible, given enough work, or would this be a hacky solution doomed to run up against countless unforeseen bugs from the start?
I don't think a solution stable enough for upstreaming is possible.