Re: Notifications and Threads
Re: Notifications and Threads
- Subject: Re: Notifications and Threads
- From: Michael Gersten <email@hidden>
- Date: Fri, 28 Jun 2002 13:41:36 -0700
BEFORE you decide to make some arbitrary throttle, or limit on the amount of DN's being sent, consider that what is an impact on system performance might vary from one person to another.
Instead of implementing an arbitrary, Apple-set limit, how about making it a per-machine settable limit?
>
From a completely different viewpoint, some people feel that the Ficus file system architechure puts too much of an overhead on things, makes file operations too slow, etc, and so Ficus hasn't been utilized much.
But Ficus lets you do things that no other system can.
Slow? What's slower, a 30% slowdown, or a 100% slowdown?
Will heavy DN's slow down the system? I might be willing to tolerate a 30%, or even 50% slowdown on a 3.6 Dual G5 processor. Especially if I need that functionality. Faster hardware is cheaper than the programmer's cost to re-write the code faster. For Apple to say "This is too slow, restrict what the app can do" is not Apple's place.
(Yea, I know, today is only 1.5 G4 or so. But next month ...)
[Ficus is now over 10 years old. Ficus had a significant CPU overhead/usage for disk I/O. What was significant CPU 10 years ago is trivial usage today.
What was significant on a single CPU a month ago is only half as much on today's dual processor, and less on next months quad board.]
>
Using distributed notifications is not really good advice. Which thread
>
processes distributed notifications is not defined. Although it might
>
tend to be the main thread much of the time, we have had people discover
>
that that is not a guarantee in the current implementation, and who
>
knows what might happen in the future...
Last I heard, the thread that processes it is whatever thread does port IO/port checking. Since most child threads never check any ports, that's not a problem. DO is really the only place where ports get checked by threads that I know of. Is DN based on DO? (Hmm... net-wide DN's across machines from a single DN server...)
Oddly enough, DO's are supposed to be the best way to notify the main thread, right? But as soon as I send a DO message that isn't one-way, I'll wait for a reply, and then start processing incoming events, right? That is how DO works, to support the server needing to call back to the client normally, right?
Does that mean (I think it does) that any "notify the main thread by DO" must be a oneway void message?
>
Plus, distributed notifications is a very heavyweight mechanism for
>
in-one-task activities. And, if we find the volume of distributed
>
notifications getting to be a problem for system performance, it is not
>
out of the question that we might throttle it to limit the number of
>
distributed notifications each app can send per second, or in some other
>
way.
>
>
Notifying the main thread has been discussed here and on the cocoa-dev
>
list @ Apple before (check the list archives for cocoa-dev at
>
lists.apple.com).
>
>
Chris Kane
>
Cocoa Frameworks, Apple
I know it's been discussed, but I just did a search for
"notify the main thread", and got nothing relavant.
Can anyone give a good quick (one line per idea) summary?
1. Thread-locked posting/retriving from an (internal) app maintained queue
2. Posting to the official app event queue (will this work?)
3. NSConnections/oneway void DO to another thread.
--
I am a Mac 10-Cocoa/WOF/EOF developer, and I'm available for hire. Please contact me at michael-job @ stb.nccom.com if interested. Resume at
http://resumes.dice.com/keybounce
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.