Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface
Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface
- Subject: Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface
- From: Kevin Meaney <email@hidden>
- Date: Wed, 16 Sep 2015 23:00:07 +0100
I can't help but think that there should be a way to use xpc services as a nice solution to this problem.
Unfortunately xpc services are mostly designed around the idea that if the service dies the app can restart it when it needs. Whereas you need the service running your experiment and collecting data to stay running even if the app displaying the results dies. When the user restarts the application it connects to the still running service.
Kevin
Sent from my iPad
> On 16 Sep 2015, at 22:28, Jean Suisse <email@hidden> wrote:
>
>
>> But I agree that this all (meaning the contortions to get updates onto the main thread) seems like too much flash and not enough bang. The easiest way would be to dispatch the original update code in blocks onto the main thread asynchronously, thus serializing them and generating KVO notifications safely.
>
> I thought of that at first, to solve the uncommitted CA transactions issues. But the syntax is ugly. And I didn’t want to post blocks from all over the place to the main thread (I have 100+ NSTextfields with number formatters updated every second… meaning as many blocks...).
> So I went for the updateUI solution, which is cleaner: It only requires me to duplicate instance variables.
>
> At this point, I would like to add that instance variables (and their UI–bound property counterpart) are mostly double with a few int, so they aren’t retained objects subjects to leaks.
>
>> When I think about it in those terms, it’s clear (to me, at least) that the *real* problem is one of coalescing a potentially large number of updates over time. In other words, this thread is really about premature optimization and its ugly consequences.
>
> The issue, to me, is to get my app to run for a few days without crashing. The only way I have to make it work, currently, is by not updating the UI.
> This is a shame considering the time I spent arranging all those textfields in a nice fashion to make it easily readable despite the large number of displayed values (and also, IB gets really really slow with that many controls on a view, making the design part a real pain).
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Lost memory, GCD, dispatch sources, Cocoa bindings & User interface (From: Jean Suisse <email@hidden>) |
| | >Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface (From: Quincey Morris <email@hidden>) |
| | >Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface (From: Charles Srstka <email@hidden>) |
| | >Re: Lost memory, GCD, dispatch sources, Cocoa bindings & User interface (From: Ken Thomases <email@hidden>) |
| | >Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface (From: Quincey Morris <email@hidden>) |
| | >Re: Lost memory, GCD, dispatch sources, ?Cocoa bindings & User interface (From: Jean Suisse <email@hidden>) |