Just to add - I personally see this feature as being far more
important
than Cocoa in the short term. It is something that many of us
( those of
use that have apps using very processor intensive code ) could gain
from
immediately.
There are ways to do that now BUT they are algorithm and application
design issues as opposed to language constructs.
There is a PreemptiveThread class (http://www.taylor-design.com/
PreemptiveThreadTDDemo.zip).
Or write your algorithm to use async shells and pass data back and
forth to achieve your goal.
Thanks for the mention! Just so everyone knows, I am planning an Intel
update, but I've been extremely busy. I thought I would get to it a couple
weekends ago, couldn't, and will try again this weekend.
Some comments on all of this:
* I don't think we're ever going to see a fully preemptive-thread safe
framework. Large parts of Win32, Carbon, and Cocoa are not thread safe.
Synchronization issues can quickly become a nightmare, especially with GUI
stuff. What I would like to see is documentation on what parts of RB are and
are not preemptive thread safe, and an effort to insure some basic stuff is
thread safe.
* I don't think any of the current language constructs should be
automatically threaded. Code would break left and right, and in difficult to
debug ways. You have to be very careful with preemptive threads in a
multicore system. Everything has to be synced, even reads (not just writes)
of a common variable or memory location. It would be interesting to have
additions so that one could, for example, tell a For...Each thread to split
the items up into x number of threads. Something like "For Each Item In List
(Split 2)" could spawn two threads for the loop. But it should be a
developer reviewed and made decision.
* It would be nice to see the parts of the framework which can benefit most
become preemptively threaded. Usually this means multimedia stuff.
* For those thinking of jumping ship to Cocoa over this: having done both, I
don't consider threading on Cocoa to be any easier than threading on RB. In
both cases you have to be careful about what APIs you call, you can't touch
GUI stuff directly, and you have to sync certain operations with semaphores.
It's the same exact set of design challenges, it's just that one is in basic
and one is in obj c. The worst thing about doing it in RB is that you have
to figure out the declares and learn about the APIs. And if you use my
class, you don't even have to do that.
Daniel L. Taylor
Taylor Design
Computer Consulting & Software Development
[EMAIL PROTECTED]
www.taylor-design.com
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
