Re: Serial IO seems to be starving UI
At 0:21 -0500 31/1/09, Michael Ash wrote: And even there, a continuous sequence of 0-delay performs should not lock the user out of your program. Seems to me that most non-user events should be interleaved in with user events based on when they occur, or at the very least given equal time. It's too easy to lock up the main event loop such that the user can no longer do anything otherwise. Yes, this can be really annoying. I ran in to it on the iPhone, where if you run a sequence of actions say every 0.01 seconds, but your action takes longer than 0.01 seconds and then the phone entirely stops accepting UI which is problematic to say the least. And very confusing to debug. It's actually good to learn *why* this was happening! Peter. -- Keyboard Maestro 3 Now Available! Now run macros from your iPhone with Keyboard Maestro Control! Keyboard Maestro http://www.keyboardmaestro.com/ Macros for your Mac http://www.stairways.com/ http://download.stairways.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Serial IO seems to be starving UI
On Jan 30, 2009, at 2:08 AM, Rick Mann wrote: Sorry for the cross-post, but I thought both these lists might have advice to offer. Please don't cross-post. Try one list, then the other. I just dusted off an app I'd worked on several months ago. It used to work fine (prior to 10.5.6), but now it behaves very erratically. I'm not blaming 10.5.6 necessarily, it's just that's all I can think of that might have changed. Basically, it uses NSFileHandle on a serial port to get notified when data is available. The data is coming in at 9600 baud. It parses the packets, then sends the packets to some code that graphs the values. I've been able to determine that valid data is coming in fairly frequently, and the packets are parsing correctly. This ends up calling -setNeedsDisplay: on my view, but the view's draw code is only called once in a very long while (30 seconds or more, but sometimes it'll get called faster). There is also a view that shows the raw bytes, and it, too, updates only when the graph view updates. I tried running Shark, but I'm not very good at using it or interpreting the results. It seems to spend 49% of the time on __semwait_signal, and 50% of the time in the read routine (with a lot of the time going to makeKeyAndOrderFront, for some reason). Like I said, this used to work pretty flawlessly, and now it's very unhappy. Any suggestions would be very welcome. What is likely happening is that the NSFileHandle processing is starving the main NSRunLoop. This happens because NSRunLoop processes non-user input before it processes user events (which seems backwards for the main run loop but is nevertheless the case). The only solution is to use a secondary runloop on a second thread to process the data, then safely get that info back to the main thread and trigger redrawing. You should likely process the data on the second thread as well so that the main thread is completely free for user events. I have no explanation of why it should suddenly not work other than that data is probably flowing in faster or requires more processing. Cheers, M ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Serial IO seems to be starving UI
On Jan 30, 2009, at 10:21:35, A.M. wrote: What is likely happening is that the NSFileHandle processing is starving the main NSRunLoop. This happens because NSRunLoop processes non-user input before it processes user events (which seems backwards for the main run loop but is nevertheless the case). The only solution is to use a secondary runloop on a second thread to process the data, then safely get that info back to the main thread and trigger redrawing. You should likely process the data on the second thread as well so that the main thread is completely free for user events. I have no explanation of why it should suddenly not work other than that data is probably flowing in faster or requires more processing. If anything, data is coming in more slowly. I used to run it at 115200, now it's at 9600. I may be able to get one of my other MBPs to run 10.5.5, and try it there. -- Rick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Serial IO seems to be starving UI
On Fri, Jan 30, 2009 at 1:21 PM, A.M. age...@themactionfaction.com wrote: What is likely happening is that the NSFileHandle processing is starving the main NSRunLoop. This happens because NSRunLoop processes non-user input before it processes user events (which seems backwards for the main run loop but is nevertheless the case). Actually it makes perfect sense. If an event causes a method to call -performSelector:withObject:afterDelay:, that selector should logically be applied before the next event is processed. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Serial IO seems to be starving UI
On Fri, Jan 30, 2009 at 8:00 PM, Kyle Sluder kyle.slu...@gmail.com wrote: On Fri, Jan 30, 2009 at 1:21 PM, A.M. age...@themactionfaction.com wrote: What is likely happening is that the NSFileHandle processing is starving the main NSRunLoop. This happens because NSRunLoop processes non-user input before it processes user events (which seems backwards for the main run loop but is nevertheless the case). Actually it makes perfect sense. If an event causes a method to call -performSelector:withObject:afterDelay:, that selector should logically be applied before the next event is processed. That's an argument for prioritizing that one particular kind of event (assuming you meant with a 0 delay, anyway) but not an argument for prioritizing *all* non-user events. And even there, a continuous sequence of 0-delay performs should not lock the user out of your program. Seems to me that most non-user events should be interleaved in with user events based on when they occur, or at the very least given equal time. It's too easy to lock up the main event loop such that the user can no longer do anything otherwise. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
