OpenEuphoria

Re: 64 bit euphoria

• Posted by Daniel Kluss <codepilot at gmail.com> Apr 23, 2005
• 501 views

Jason Gade wrote:
> 
> jacques deschênes wrote:
> > 
> > Robert Craig wrote:
> > > 
> > > Kenneth Rhodes wrote:
> > > > Also, it seems that hence forth the 64bit cpus will multi-core,
> > > > so shouldn't threads be a "must" feature for the next version of
> > > > Euphoria?
> > > 
> > > My main concern with threads isn't how to implement them,
> > > it's what are people going to do with them? Can any of the
> > > pro-thread people give some examples (that couldn't easily be done
> > > some other way, such as the Language Wars technique, or simply
> > > using multiple processes communicating via shared memory)?
> > > 
> > > Regards,
> > >    Rob Craig
> > >    Rapid Deployment Software
> > >    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> > > 
> > 
> > 1) threads inside the same process take less resources than 2 processes
> > communicating.
> 
> True, but how much does this affect current hardware/software(OS's)?
Well threading would be faster, buit people have argued that the 386 is 
all anyone should ever need. Shoot with todays manufacturing process(90nm), the
386 would probably be too small to see, and super cheap.(hmm multicore(like 1000
of them) 386
is a good thing)
> 
> > 2) a thread switching is faster (more efficient) than a context (process)
> > switching.
> 
> See above question -- is it really an issue?  *nixes preferred heavy processes
> over
> threads for a long time.  I read something comparing *nix threads vs.
> processes and
> there wasn't that big a difference between the two.
Processes should be more robust, but threading does have its place. Here though
I don't know, but I would like it.
> 
> > 
> > 3) One obvious usage of threads is to get a more responsive applications. I
> > hate
> > those situation where the application doesn't answer to mouse click
> > (keypress)
> > because it's caugth in a waiting loop for some network resource or something
> > else.
> > So when the application is designed with a thread for the user interface and
> > a
> > thread for others cores,  the user interface keep responding.
> 
> Couldn't this be done with callbacks?
No actually, callbacks require the thread to be in a waiting state,
they only callback when waiting for getmessage or the like.
There is NO way to communicate between processes( And I've looked ) that is
non-blocking, and would allow one to handle the GUI and the other to handle
the network resources. Although Shared memory and polling it does come close.
> 
> In modern OS's, how many API calls are blocking calls versus taking a
> callback?
There are lots of callbacks in windows, but windows was designed for 
multithreading programs, even the callbacks, you cannot make a responsive
program that has to wait for anything, or does any processing, even with
callbacks
without threading.
> 
> > 
> > 4) why to bother designing threads machanics inside the application when it
> > already exist in the operating system in a more flexible an efficient way.
> 
> Of course the OS needs to support it, but the application (Euphoria) would
> still need
> to have infrastructure for starting new threads and synchronization/locking
> for global
> resources.  Otherwise someone could just write a library using the existing
> infrastructure.
> 
> Wouldn't much of the interpreter/translator have to be rewritten to be
> reentrant as
> well?
ALL of the interpreter(backend) and some of the translator out put would need
to be gone over, and changed. But it might be worth it.
Dan

> 
> > 
> > regards,
> > Jacques Deschenes
> > 
> 
> =====================================
> Too many freaks, not enough circuses.
> 
> j.
>