realbasic-nug
[Top] [All Lists]

Re: Dealing with multi-processor or multi-core

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: Dealing with multi-processor or multi-core
From: Daniel Stenning <d0stenning at msn dot com>
Date: Fri, 30 May 2008 20:31:40 +0100
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
Thread-index: AcjCi8h9B0jp5C5/Ed2PAgAbY5KfzA==
Thread-topic: Dealing with multi-processor or multi-core
What might help is some facility in the RB language to support  "shared
memory".  This requires semaphores etc but is faster when we need to share
big amounts of data amongst several processes ( or helper apps ).  Passing
huge chunks of data via IPC is slow. Mayb Christian has something for this
already - I don't know..


On 30/5/08 19:12, "Peter K. Stys" <pkstys at gmail dot com> wrote:

> 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.

Cheers,
Dan




_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>