OpenEuphoria

Re: marry christmas

• Posted by Vincent <darkvincentdude at yahoo.com> Dec 27, 2005
• 522 views

Al Getz wrote:
> 
> Hi Vincent,
> 
> My own task stuff is basically the same thing: either there is a function
> that must be called mid-task or else the 'task' has to return (temporarily)
> to allow the system to make another determination.
> I havent found this to be a problem because when i write the code i can
> insert some sort of task yielding call or write the task so it's embodied
> inside a procedure or function that returns temporarily to allow the
> system to respond.
> Problem is, if i didnt write the code then there's no way to yield so these
> methods fail as you noted, but another work around might be to write
> a server instead of a program (or even two or more servers) and have the
> main program work with the server(s).  I've done this already with one
> of my programs called "In Place Scientific Calculator", which is basically
> a function calculator engine wrapped as a server.
> Once you create a server, you can have programs interacting through
> the server, share data, as well as post messages (so they dont have to
> wait around for the return value).  Since the server runs in a different
> process it's got to be thread independent of the main program.
> If this is to your liking,  perhaps you can try this method using Euphoria.
> As noted, it's got some benefits that go beyond threads alone too...
> another one is that the server does not crash even if the main program does,
> so any data saved through the server is still resident and accessable
> through the main program (once it's started again).
> 
> If you end up doing something like this i'd like to hear about
> your experiences with it.

Hi Al,

Your server IPC method sounds interesting... perhaps I'll experiment with it
too.

I currently testing out a Memory Mapped File IPC (shared memory) method. I was
wrapping the Win32 Mutex and Semaphore synchronization API, but quickly noticed
that Patrick Barnes has already done it. A Linux and FreeBSD port is still needed
though.

I successfully written a simple multi-process program that communicates between
five blocks of shared memory. The program consists of three main files and one
loader file. Assuming all four processes have high enough priority and CPU usage,
Windows should place each process on a seperate core with quad-core and quad
processor systems *or* dual-core /w Hyper-Threading and dual processor /w
Hyper-Threading systems. Since all the processes can share data and rely on each
other for computation, true parralelism might be possible on those systems. Of
course on single core, single processor systems, only hardware-level context
switching can occur.

In general, multi-process programming is less efficent than multi-thread
programming in Windows because context switching between processes is more
expensive than with threads; but at least we *might* have alternatives to
cooperative multi-tasking in the future (until Rob implements true
thread-safety). 


Regards,
Vincent