OpenEuphoria

RE: Threads......

• Posted by gertie at ad-tek.net Jul 06, 2001
• 397 views

On 6 Jul 2001, at 12:51, SR.Williamson wrote:

<snip>

> I only understood a teensie bit of any of that, but I'm going to smash 
> on with my questions anyway, even if they were just answered, since I 
> couldn't tell anyway if they *had* been answered.
> 
> Would the programs still need to talk to each other? 

If the purpose was to appear to be simultaneously responding to different
inputs, even
tho the code for each input takes a long time to exec or isn't reentrant, you
need other
instances of code to deal with the inputs. For instance, in getting a web page,
the
puter may not recieve it from the net for a minute or so. If all it can do is
wait on the
webpage once you ask for it, then you can't do anything else to/with the program
until
it is done waiting for that webpage.

Another way to handle this example is to retrieve a little of the page from
socks, then
check user input, then get a few more bytes from socks, then check user input,
etc.,
in effect, you would be using the OS's winsock thread to buffer the input. This
isn't
always possible or desireable.
 
> Would that be a bad thing if they did? I can imagine writing a program 
> that does something very simple, and having someone write another 
> program that uses my program to do what it does, and someone else's 
> program to do its thing, and then organizing and coordinating the 
> results. Wouldn't that be good, and open some unique possibilities for 
> programs? Would it be a security risk?
>
> Didn't someone say this could kinda be done now using the Eu sockets/TCP 
> library? If so, can anyone hack together an example showing me how to do 
> this with multiple Eu programs (even if it means I have to copy the 
> interpreter or bind the program) on the *same* machine?

Look at the mirc-Eu example in the archives, or the DDE examples in the user 
contributions. The mirc program can be another Eu program or another mirc
program.
DDE is invisable to other machines, but cannot be used over a net.  Another
approach
is the ole dos approach, spawn a new dos command interpreter (command.com), and 
tell it to run another program, that program reads the ini file you set up for
it, and writes
it's results to a file. When it stops running, the original program gets cpu
back and
reads the results file. This can be pretty fast if a ramdrive is used.

Kat