Kernel interface for Wine synchronization primitives

[Zebediah Figura (she/her)]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20210119/62b164ad/attachment.sig>