> The first thing I'd look at, is what is going on for a couple of minutes >while the program is coming up? Would that have to happen for every process???
Startup involves loading a >1GB data matrix from disk into memory. Transformations are then done using this matrix on the 1MB data blocks that are sent in via TCP/IP. That's why I can't simply start new tasks on-demand, the startup time is prohibitive so that complicates things. The first option (multiple processes) seems more robust but also harder to implement. Are there any design guidelines for implementing a "server" in Cocoa? ________________________________ From: Scott Ribe <[email protected]> To: Jon Sigman <[email protected]> Cc: Cocoa- Dev List <[email protected]> Sent: Tuesday, September 13, 2011 9:55 AM Subject: Re: Task dispatching On Sep 13, 2011, at 10:42 AM, Jon Sigman wrote: > Design-wise, should I have a lightweight front-end process that accepts all > inbound requests and then dispatch the requests to one of the other idling > processes? That is an extremely common idiom for servers. Whether you should do that, or multiple worker threads, really depends on your specific app. - Multiple processes incur some more overhead in communicating data back and forth, but a crash in any single server process only affects a single client. - Multiple threads allow the data to be handed off with no overhead, but a crash anywhere affects all clients. And of course there are many many other considerations ;-) The first thing I'd look at, is what is going on for a couple of minutes while the program is coming up? Would that have to happen for every process??? -- Scott Ribe [email protected] http://www.elevated-dev.com/ (303) 722-0567 voice _______________________________________________ Cocoa-dev mailing list ([email protected]) 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]
