Array of struct And to And onto and ...

[Dar Scott]

On Monday, May 27, 2002, at 12:30 PM, Geoff Canyon wrote:

>
>> What about Multi-threading ?
>
> In general, multi-threading slows a computer down (time is spent 
> switching contexts that could have been spent doing actual work). 
> The send...in construct allows some of the same functionality with 
> less overhead.

I think this characterization of multi-threading is too strong.  
(At least, I would like to think so; I elected to use 
multithreading in much of my programming over the years.)

I agree that "send...in" allows some of the same functionality and 
I have used that to great advantage (with callbacks).  I like it 
because each handler executes for only a very short time.  I can 
effectively have several tasks going at the same time.  However, 
not everybody is comfortable with this style of programming.  Even 
those who are might find some algorithms hard to cast into this 
form.

Good news:  I haven't tried it yet ("send...in" works for me), but 
I think one can have _one_ long background task written in a 
traditional way if the code is sprinkled appropriately with 
"wait...with messages" with a non-zero time.  The wait is not a 
real "yield", but it will allow the regular quick handlers to 
execute.  (The one-task constraint is not hard and fast; issues 
come up if you have more than one.)

In both methods a non-zero time needs to be used to handle events.  
In a computation-based background task, care should be taken to 
avoid putting these delays at too low of a level.

For what I'm doing with Revolution, I don't miss multi-threading.  
And my apps can walk and chew gum at the same time.

Dar Scott