1. RE: Threads......
This explains how to do threads with C and WIN32
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_multithreading_with_c_and_win32.asp
Bernie
2. RE: Threads......
Derek Parnell wrote:
> Yeah, it a big learning curve. Threads alone are difficult enough
> without
> trying Microsoft's implementation of them.
what's difficult about it? it's just like using pthreads except
different syntax and function names, and it runs on a less stable OS ;)
3. RE: Threads......
gertie at ad-tek.net wrote:
> On 6 Jul 2001, at 1:07, euman at bellsouth.net wrote:
>
>
>
> >
> > this would mean multiple programs not just the code
> > to do the threading wouldnt it Kat?
> >
> > I thought about how threads work and thought about
> > multiple instances of the interpreter as well, I dont
> > see an easy way. The problem would be that the programs
> > would need to talk to each other
>
> If the thread's purpose was to start the interpreter and interpret one
> of our programs,
> then it's doing what we tell it. The structures the thread manager made
> in memory
> would be in the Eu program's space then. And since the thread manager is
> the one
> that started it, the thread manager would handle our inter-process
> communications,
> thinking it was regular inter-thread communication, right?
>
> Kat
>
> > there is a command: GetCurrentThread that is a constant
> > pseudo handle but Im reading this now.
> >
> > Also,
> > CreateRemoteThread and SHCreateThread that can be used
> > by COM objects but I havent gotten that far yet.
> >
> > Euman
> > euman at bellsouth.net
> >
> >
> >
> >
> > ----- Original Message -----
> > From: <gertie at ad-tek.net>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Thursday, July 05, 2001 23:11
> > Subject: Re: Threads......
> >
> >
> > >
> > >
> > > On 5 Jul 2001, at 21:33, Jeffrey Fielding wrote:
> > >
> > >
> > > >
> > > > But Euphoria is non-reentrant... I tried writing a thread library for
> > > > Euphoria on linux. call_back worked okay for interfacing with pthreads,
> > > > but
> > > > since Euphoria is non-reentrant, the program didn't work very well.
> > >
> > > What if the thread was to exec an instance of the interpreter with the
> > thread's code as
> > > the run parameter? Then the interpreter wouldn't need to be reentrant,
> > > and if
> > the
> > > structures that are set up by the thread calls were in the same memory
> > > space
> > that the
> > > thread handler set up, everything could work peachie keen, yes? The Eu
> > > program
> > > could access the structures, know it's ident, and talk to the thread api
> > properly?
> > >
> > > Kat
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?
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?
4. RE: Threads......
- Posted by gertie at ad-tek.net
Jul 06, 2001
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
5. RE: Threads......
gertie at ad-tek.net wrote:
> DDE is invisable to other machines, but cannot be used over a net.
> Another approach
i think there's something called NetDDE, but i forgot how it's used(if
DDE is even used anymore)
