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
