2008/12/4 Joseph Kelly <[EMAIL PROTECTED]>: > I've used both the CF and NS timer apis in many different situations without > a hitch. They're fairly reliable. Perhaps you could explain your "can't use > a runloop" restriction -- e.g. if you are writing a daemon or a kext, this > is not the list you want to post to.
I'm not writing a daemon or a kext. I'm porting a framework that I've designed and used on .Net before that will form the foundation of my architecture for my future Mac OS applications (I'm new to Mac OS programming). The framework is used for easy communication and synchronization between threads, processes and computers (with the same "syntax") and make it possible to design an application in small modules that communicates via messages and it's straightforward to start with the modules as threads in a single application and then split into several processes on a computer or ever distribute certain modules to other computers without changing much (or any) code at all. But mainly it makes it easier to write efficient multithreaded applications that "work". I'm very happy with the messaging framework and would like to use it on Mac OS X as well. Run loops are not compatible with this approach since my threads need to run forever or block in my framework when they are waiting for messages (the timers are used to generate timer messages internally in the framework). The threads are not event driven and will not return to the run loop. > You might find if you refactor your design a bit, that it will take to a > runloop model quite well. In fact, most of the user space IOKit async > routines require that you use a runloop. I don't "want to" refactor my design. :-) To do that, I would have give up the framework design completely. I'm generally happy with the design just want to make a good port to Mac OS X. > Also, the Mach APIs are not strictly private -- the headers are publicly > available. They are subject to change between releases, so if you do start > using them, you will need to stay on top of things -- check your binaries on > pre-release OS seeds etc. Okay, thats great to know. But I suppose it's still begging for trouble, if you can avoid it. > Joe K. _______________________________________________ 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 [EMAIL PROTECTED]
