2013/12/9 Ted Unangst <t...@tedunangst.com>: > On Mon, Dec 09, 2013 at 19:49, Vadim Zhukov wrote: >> So what's the decision? >> >> Are there any objections still? If not, can I have a pair of okays? >> KDE4 really needs a decision to be made: people already had apps >> crashing without this diff, so I've put a dirty hack to stop KDE using >> of process-shared semaphores. But there could be more dragons, in >> other software. > > If we go back to returning ENOMEM or whatever in sem_init, does that > fix KDE?
If we stop pretending we support shared unnamed semaphores, then, yes, this will help KDE. But I cannot gurantee there will be no other fallout. This needs a deep scan of all ports source as minimum... > I don't mean to be a dick about this, but in general here's how we do > things. If a feature is added and it introduces a regression, we > revert. We don't dig the hole deeper by committing an even more > intrusive diff. I'm agree, this is a good practice. > I'm not saying the diff is bad or can't be made to work, but I don't > like using "KDE needs this now" to rush it in if there are other > options. I also don't think the thing you're doing with the spinlock > is something we want. This was done to avoid polluting exported symbols. It's ugly, yes. I do not see any better option that doesn't involve rewriting entire locking in librthread, though; I hope that I just miss something obvious. > I want time to get that right. I'd rather disable shared semaphores totally, until all issues are fixed, then. I don't see a point in having half-working stuff in tree which gets picked up and used. Yes, it was my bad too that I didn't thought about sharing semaphores via mapped memory in the first place. -- WBR, Vadim Zhukov
