> On Sep 14, 2016, at 6:32 PM, John DeSoi <[email protected]> wrote: > > Hi Cannon, > >> On Sep 14, 2016, at 4:35 PM, Cannon Smith <[email protected]> >> wrote: >> >> I wondered about that. I would have thought that would be pretty rare if the >> code was structured right, but it sounds like you ran into it quite often? > > Yes, I ran into it all the time and it has nothing to do with problem code > structure. It has to do with two rules that are common in Mac environments > that support multi-processing. > > 1. All user interface and interaction must occur on the main thread. > > 2. No I/O or long execution can occur on the main thread -- otherwise the > interface is locked up. > > So everything ends up being done with callbacks.
I only started writing Cocoa apps about 10 years ago, but I haven’t run into any real problems with the Cocoa way of doing things. Especially now with NSOperationQueue/NSOperation or GCD and blocks, it has become very easy to write multi-threaded code. Back in the days of using NSThread it was probably more work and more annoying, but even then there was performSelector:onMainThread:waitUntilDone:. Nowadays there are so many more options. I think the only time I’ve ever even had to implement a callback is for file system event notifications. However, I’d be hard-pressed to think of anything to use 4D’s implementation of worker threads (as I’ve heard them discussed) that wouldn’t be easier to accomplish some other way. For example, will CALL FORM be able to be implemented as elegantly as Cocoa’s NSNotification system? Or will it be the same level of terrible as CALL PROCESS and On Outside Call? Jim Crate ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
