On Sat, Dec 21, 2013 at 12:42, Mark Kettenis wrote:
> As Ted pointed out, the size of the struct (or union) becomes part of
> the ABI. So we should probably reserve a bit more space than we
> actually need for the implementation. That way, we'll leave some room
> for experimentation. Wasting a b
> Date: Sat, 21 Dec 2013 02:29:49 -0500
> From: Ted Unangst
>
> On Sat, Dec 07, 2013 at 14:11, Vadim Zhukov wrote:
> > This patch fixes problems in KDE4, that relies on sharing (process-shared)
> > semaphores via mmap(). This feature is used in the wild, so if we claim
> > that we support process
On Sat, Dec 07, 2013 at 14:11, Vadim Zhukov wrote:
> This patch fixes problems in KDE4, that relies on sharing (process-shared)
> semaphores via mmap(). This feature is used in the wild, so if we claim
> that we support process-shared semaphores, we have to implement it, too.
Haven't forgotten abo
On Wed, Dec 11, 2013 at 11:12, Vadim Zhukov wrote:
>> 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
2013/12/9 Ted Unangst :
> 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 ha
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 proc
2013/12/8 Philip Guenther :
> On Sat, Dec 7, 2013 at 10:35 AM, Ted Unangst wrote:
>> One of the hallmarks of the original libpthread was that all data
>> structures were opaque, and hidden via pointers. That in turn made it
>> possible to write a binary compatible librthread. I never would have
>>
On Sat, Dec 7, 2013 at 10:35 AM, Ted Unangst wrote:
> One of the hallmarks of the original libpthread was that all data
> structures were opaque, and hidden via pointers. That in turn made it
> possible to write a binary compatible librthread. I never would have
> started librthread if it hadn't b
07.12.2013 22:35 пользователь "Ted Unangst" написал:
>
> On Sat, Dec 07, 2013 at 21:32, Vadim Zhukov wrote:
> > 2013/12/7 Ted Unangst :
> >> On Sat, Dec 07, 2013 at 14:11, Vadim Zhukov wrote:
> >>> This patch fixes problems in KDE4, that relies on sharing
(process-shared)
> >>> semaphores via mmap
On Sat, Dec 07, 2013 at 21:32, Vadim Zhukov wrote:
> 2013/12/7 Ted Unangst :
>> On Sat, Dec 07, 2013 at 14:11, Vadim Zhukov wrote:
>>> This patch fixes problems in KDE4, that relies on sharing (process-shared)
>>> semaphores via mmap(). This feature is used in the wild, so if we claim
>>> that we s
2013/12/7 Ted Unangst :
> On Sat, Dec 07, 2013 at 14:11, Vadim Zhukov wrote:
>> This patch fixes problems in KDE4, that relies on sharing (process-shared)
>> semaphores via mmap(). This feature is used in the wild, so if we claim
>> that we support process-shared semaphores, we have to implement it
On Sat, Dec 07, 2013 at 14:11, Vadim Zhukov wrote:
> This patch fixes problems in KDE4, that relies on sharing (process-shared)
> semaphores via mmap(). This feature is used in the wild, so if we claim
> that we support process-shared semaphores, we have to implement it, too.
>
> This changes the
This patch fixes problems in KDE4, that relies on sharing (process-shared)
semaphores via mmap(). This feature is used in the wild, so if we claim
that we support process-shared semaphores, we have to implement it, too.
This changes the sem_t definition: it becomes a synonim to struct __sem
instea
13 matches
Mail list logo
