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: Charles Yeomans <charles at declareSub dot com>
Date: Fri, 30 May 2008 13:24:49 -0400
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> <p06240804c465e06353d5 at [62 dot 161 dot 36 dot 122]> <D01600E9-BB0D-49DF-8990-65E4B1F93D14 at tolisgroup dot com> <48403707 dot 7080306 at alphaview dot com>
It depends on how one defines "gain".  In your case, the master app  
should remain responsive, and if the download process crashes, the  
master app should not.

Charles Yeomans

On May 30, 2008, at 1:19 PM, Giovanni wrote:

> But even on a single processor, you would see a tremendous gain if the
> required process is doing stuff like a downloader helper app. The  
> helper
> app would continue to download while the master app would remain  
> highly
> responsive. Would that be right?
>
> Giovanni
> ----------------------
>
>
>
> Tim Jones wrote:
>> On May 30, 2008, at 9:54 AM, Jean-Luc Arnaud wrote:
>>
>>
>>> Thanks for information, Joe.
>>>
>>> Could you say a little bit more on helper app, or give us links to
>>> articles ?
>>>
>>> Perharps, I'm doing so without knowing it. My main app runs as many
>>> apps as necessary for achieving parallel tasks. Of course, there is
>>> communication flow between main app and daughters apps.
>>>
>>
>> That's a perfect description.  Here's an example of one of my  
>> projects:
>>
>> We have a pair of tools that run from the command line.  One talks to
>> the server app for our system while the other actually performs  
>> data I/
>> O for the movement of data between the client system and the server.
>> We can be managing multiple operations from within a single  
>> management
>> console and each of the shelled copies of the communication tool will
>> be running as a separate process.  If we are running on a multi-proc
>> system, there is a good chance that the executive will run each
>> instance on a different processor/core.  It's just one of the things
>> that the Unix paradigm provides without the headaches discussed
>> concerning managing multiple preemptive threads.
>>
>> However, I do take things one step further and execute each of the
>> streams above in its own RB cooperative thread to ensure the UI stays
>> responsive.
>>
>>
>>> Should I benefit of multitasking, doing that ? It seems like I don't
>>> (perharps badly coded !!).
>>>
>>
>> I suspect that you are if you have a multi-proc system.  Of course,
>> there's no real win outside of more elegant process management if
>> you're on a single proc system...
>>
>> Tim
>>
_______________________________________________
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>