| To: | "REALbasic NUG" <realbasic-nug at lists dot realsoftware dot com> |
|---|---|
| Subject: | Re: Dealing with multi-processor or multi-core |
| From: | "Peter K. Stys" <pkstys at gmail dot com> |
| Date: | Fri, 30 May 2008 12:12:04 -0600 |
| Authentication-results: | mx.google.com; spf=pass (google.com: domain of realbasic-nug-bounces at lists dot realsoftware dot com designates 66.116.103.65 as permitted sender) smtp dot mail=realbasic-nug-bounces at lists dot realsoftware dot com |
| Delivered-to: | listarchive at realsoftware dot com |
| Delivered-to: | realbasic-nug at lists dot realsoftware dot com |
| References: | <p06240802c4657bd7c318 at 62 dot 161 dot 36 dot 122> <41B4C50C-AB85-4975-B2AE-C6A4DD49D787 at inspiringapps dot com> <48400D8C dot 7090301 at chrononomicon dot com> <0FE2A07A-841A-4C6A-92A8-878E7F9CEEBB at inspiringapps dot com> |
On Fri, May 30, 2008 at 8:32 AM, Joe Strout <joe at inspiringapps dot com> wrote: > > Yes, exactly. Separate processes will be scheduled preemptively and, > on multicore machines, may be distributed across the multiple cores. > Yet because they're separate processes and don't share memory, all the > subtle thread-safety issues that plague preemptively multithreaded > programs simply go away. > Sounds attractive, but then what is the best way to pass/retrieve data to/from such processes, short of writing/reading files which may defeat the speed advantage of multiple cores? P. -- --------------------------------------------- Peter K. Stys, MD Dept. of Clinical Neurosciences Hotchkiss Brain Institute University of Calgary tel (403) 210-8646 --------------------------------------------- _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html> |
| Previous by Date: | Re: Dealing with multi-processor or multi-core, Giovanni |
|---|---|
| Next by Date: | Re: Dealing with multi-processor or multi-core, Norman Palardy |
| Previous by Thread: | Re: Dealing with multi-processor or multi-core, Joe Strout |
| Next by Thread: | Re: Dealing with multi-processor or multi-core, Norman Palardy |
| Indexes: | [Date] [Thread] [Top] [All Lists] |