I was not aware that we can see the cpu processes ;)
Ok so to make a multiprocessor app.
1 create a "master app"
2 create "slave/helper apps"
3 communicate between master and slave/helper via ipcsockets.
If master app collapses, use a helper app to terminate all other apps?
Giovanni
•••••••••••••••••
On May 30, 2008, at 7:39 AM, "Glenn L. Austin" <glenn at austin-home dot com>
wrote:
> On May 30, 2008, at 7:22 AM, Bart Silverstrim wrote:
>
>> Joe Strout wrote:
>>
>>> Get over it. Preemptive multitasking is, in general, very bad mojo.
>>> If you access ANY functions that are not thread-safe (and this would
>>> include pretty much the entire framework, as well as many of the OS
>>> functions that you use even for simple things like drawing to a
>>> window), then your program will have obscure bugs that will crop up
>>> in
>>> odd circumstances after your software is released. The Windows
>>> platform layer used to use preemptive threads, and it was a
>>> nightmare
>>> -- one that ended only when they coded a cooperative multitasking
>>> system like the Mac already had.
>>
>> Could you elaborate on this? I thought all NT lineage was
>> preemptively
>> multitasking, with a Win16 compatibility system for older
>> applications
>> that was cooperatively multitasked within itself...?
>
> But the NT scheduler (through XP) absolutely sucked in terms of
> permitting a single process to "starve" other processes. That has
> been improved with Vista.
>
>>> To make use of multiple processors safely (in ANY language), you
>>> need
>>> to divide your work into separate processes. In RB, the best way to
>>> do this is via a helper app that you would access via the Shell.
>>> It's
>>> not that hard to do, and it's 100% safe.
>>
>> You're saying design your app to be multiprocess and not
>> multithreaded?
>
>
> Design it to be multi-processor-aware, and you're far better off than
> multi-threaded. When you start thinking "multiple processors" you
> start thinking about contention for resources (multiple processors
> attempting to access the same resource) and parallelizing your tasks
> by reducing "sync points" between multiple processes.
>
> Threading (and parallel processing) is something that a lot of people
> want to be able to do, but there are so many pitfalls that most people
> don't get it right.
>
> (I've been designing parallel processing systems since 1987 -- it's
> NOT as easy as it looks!)
>
> --
> Glenn L. Austin <><
> Computer Wizard and Race Car Driver
> <glenn at austin-home dot com>
> <http://www.austin-home.com/glenn/>
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|