> On Dec 15, 2015, at 6:27 PM, Kevin Ballard wrote:
> On Tue, Dec 15, 2015, at 06:12 PM, John McCall wrote:
>> So, just to complete the loop here: absent Darwin granting public and
>> backwards-compatible access to an internal API, we need to write this in a
>> way that falls back on using a hea
On Tue, Dec 15, 2015, at 06:12 PM, John McCall wrote:
> So, just to complete the loop here: absent Darwin granting public and
> backwards-compatible access to an internal API, we need to write this in a
> way that falls back on using a heavyweight lock in the presence of
> contention. I’m fine
> On Dec 15, 2015, at 6:01 PM, Greg Parker via swift-dev
> wrote:
>> On Dec 15, 2015, at 5:32 PM, Kevin Ballard wrote:
>>
>>> On Tue, Dec 15, 2015, at 01:38 PM, Greg Parker via swift-dev wrote:
>>>
>>> Another solution is to use a handoff lock algorithm. This is what libobjc
>>> does now. The
> On Dec 15, 2015, at 5:32 PM, Kevin Ballard wrote:
>
>> On Tue, Dec 15, 2015, at 01:38 PM, Greg Parker via swift-dev wrote:
>>
>> Another solution is to use a handoff lock algorithm. This is what libobjc
>> does now. The lock owner stores its thread ID in the lock. Each lock waiter
>> yields
On Tue, Dec 15, 2015, at 01:38 PM, Greg Parker via swift-dev wrote:
>
> Another solution is to use a handoff lock algorithm. This is what libobjc
> does now. The lock owner stores its thread ID in the lock. Each lock waiter
> yields to the owner thread specifically, donating its priority and res
> On Dec 14, 2015, at 7:51 PM, Mike Ash wrote:
>
>> On Dec 14, 2015, at 3:19 PM, Greg Parker via swift-dev
>> wrote:
>>
>>> On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev
>>> wrote:
>>>
On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote:
#3 sounds like a great approach to
On Mon, Dec 14, 2015, at 07:48 PM, Greg Parker wrote:
>
> > On Dec 14, 2015, at 7:39 PM, Kevin Ballard wrote:
> >
> >> On Mon, Dec 14, 2015, at 07:34 PM, Greg Parker wrote:
> >>
> >>> On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev
> >>> wrote:
> >>>
> On Mon, Dec 14, 2015, at
> On Dec 14, 2015, at 3:19 PM, Greg Parker via swift-dev
> wrote:
>
>
>> On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev
>> wrote:
>>
>>> On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote:
>>> #3 sounds like a great approach to me. I agree with Kevin that if we keep
>>> the object h
> On Dec 14, 2015, at 7:39 PM, Kevin Ballard wrote:
>
>> On Mon, Dec 14, 2015, at 07:34 PM, Greg Parker wrote:
>>
>>> On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev
>>> wrote:
>>>
On Mon, Dec 14, 2015, at 12:19 PM, Greg Parker via swift-dev wrote:
> On Dec 14, 2015,
On Mon, Dec 14, 2015, at 07:34 PM, Greg Parker wrote:
>
> > On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev
> > wrote:
> >
> >> On Mon, Dec 14, 2015, at 12:19 PM, Greg Parker via swift-dev wrote:
> >>
> >>> On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev
> >>> wrote:
> >>>
>
> On Dec 14, 2015, at 7:26 PM, Kevin Ballard via swift-dev
> wrote:
>
>> On Mon, Dec 14, 2015, at 12:19 PM, Greg Parker via swift-dev wrote:
>>
>>> On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev
>>> wrote:
>>>
On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote:
#3 sounds li
On Mon, Dec 14, 2015, at 12:19 PM, Greg Parker via swift-dev wrote:
>
> > On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev
> > wrote:
> >
> >> On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote:
> >> #3 sounds like a great approach to me. I agree with Kevin that if we keep
> >> the objec
> On Dec 14, 2015, at 9:47 AM, John McCall via swift-dev
> wrote:
>
>> On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote:
>> #3 sounds like a great approach to me. I agree with Kevin that if we keep
>> the object husk approach that any use of a weak pointer that returns nil
>> should drop an
> On Dec 12, 2015, at 7:04 PM, Chris Lattner wrote:
> #3 sounds like a great approach to me. I agree with Kevin that if we keep
> the object husk approach that any use of a weak pointer that returns nil
> should drop any reference to a husk.
Spin locks are, unfortunately, illegal on iOS, which
#3 sounds like a great approach to me. I agree with Kevin that if we keep the
object husk approach that any use of a weak pointer that returns nil should
drop any reference to a husk.
-Chris
> On Dec 11, 2015, at 7:00 AM, Mike Ash via swift-dev
> wrote:
>
> 3. Borrow a bit from the weak poi
On Dec 12, 2015, at 3:29 AM, Kevin Ballard via swift-dev
wrote:
>
> On Sat, Dec 12, 2015, at 12:01 AM, Kevin Ballard wrote:
>> Another possible fix is to just atomically load/store the Value pointer
>> itself (assuming all platforms Swift runs on supports lock-free atomic
>> pointers). This wa
On Sat, Dec 12, 2015, at 12:01 AM, Kevin Ballard wrote:
> Another possible fix is to just atomically load/store the Value pointer
> itself (assuming all platforms Swift runs on supports lock-free atomic
> pointers). This way if the object is deallocating, it would attempt an atomic
> CAS on the
On Fri, Dec 11, 2015, at 07:00 AM, Mike Ash via swift-dev wrote:
>
> Increasing the inline size of weak references opens up the possibilities a
> bit. I can think of at least four fixes:
>
> 1. Delete the zeroing, and otherwise leave things as-is. This extends the
> life of the object husk (by
> On Dec 10, 2015, at 10:55 PM, John McCall wrote:
>
> The intent is that weak references do not need to be safe against read/write
> and write/write races. They do need to be safe against read/destroy and
> write/destroy races (by “destroy”, I mean destruction of the object, not the
> weak
> On Dec 10, 2015, at 6:50 PM, Mike Ash via swift-dev
> wrote:
> Hello, world!
>
> First, congratulations on the whole open source thing. I'm really pleased to
> see how the team set it up and how well it's going. Blew away my expectations.
>
> Anyway, on to the thing.
>
> I was looking throu
Hello, world!
First, congratulations on the whole open source thing. I'm really pleased to
see how the team set it up and how well it's going. Blew away my expectations.
Anyway, on to the thing.
I was looking through the standard library's implementation of weak references,
as one does, and no
21 matches
Mail list logo
