Re: [xine-devel] Patch for kxine to work

[Miguel F. <mi...@ce...>]

Hi Mark, Bastien,

On Fri, 2002-08-09 at 15:20, Mark Thomas wrote:
> I don't think that's what I want.  Thanks, though.
> 
> >I'd like to hear from one of the trolls indeed.
> >
> 
> I'll start crafting a mail to them, then.  I don't think they can change
> it though: I suspect there is a reason they use a generic pthread mutex
> rather than the XLockDisplay mutex (possibly because there are no
> XIsDisplayLocked, or XTryLockDisplay functions, which I think are
> neccessary for some parts of Qt).


>From the info i got in this thread i had the impression that QT is
wrong: it does a quite big assumption that it's the only one playing
with X stuff. no X locks would be needed since everything must be
already protected by the big QT lock.

imho, qt should be playing host's rules and in case of X it might
involve the XLockDisplay just before X access. It would be used together
with an already taken QT lock. The only problem i can think now is an
unlikely deadlock situation if someone acquire locks at the inverse
order (X and then QT). it doesn't makes much sense though.

Since the trolls are unlikely to change it, isn't possible for you in
kxine (by using some qt event or something) to explicity lock X? i have
a feeling that it would be difficult.

So if we have no other solution i think we can apply this patch, it
shouldn't cause any harm. but this is not xine's fault, we will be
workarounding someone else mistakes...

regards,

Miguel