1. Threads......
- Posted by euman at bellsouth.net
Jul 05, 2001
Threads are impossible for me useing strictly Euphoria.
-- start threads
hThread1 = call_back(routine_id("Thread1"))
hThread2 = call_back(routine_id("Thread2"))
hThread1 = c_func(xCreateThread,{NULL, NULL, hThread1, NULL,
NORMAL_PRIORITY_CLASS, thread1})
hThread2 = c_func(xCreateThread,{NULL, NULL, hThread2, NULL,
NORMAL_PRIORITY_CLASS, thread2})
The call_back address is not a *real* proc address
I will have to create a .dll for use, useing Masm32 or Borlands C++.
I need to learn a few things to do this so no-one hold their breathe.
Something like this would be more valuable than namespace
in my opinion.
Later,
Euman
euman at bellsouth.net
2. Re: Threads......
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.
Jeff
----- Original Message -----
From: <euman at bellsouth.net>
To: "EUforum" <EUforum at topica.com>
Subject: Threads......
>
>
> Threads are impossible for me useing strictly Euphoria.
>
> -- start threads
> hThread1 = call_back(routine_id("Thread1"))
> hThread2 = call_back(routine_id("Thread2"))
>
> hThread1 = c_func(xCreateThread,{NULL, NULL, hThread1, NULL,
> NORMAL_PRIORITY_CLASS, thread1})
> hThread2 = c_func(xCreateThread,{NULL, NULL, hThread2, NULL,
> NORMAL_PRIORITY_CLASS, thread2})
>
> The call_back address is not a *real* proc address
>
> I will have to create a .dll for use, useing Masm32 or Borlands C++.
> I need to learn a few things to do this so no-one hold their breathe.
>
> Something like this would be more valuable than namespace
> in my opinion.
>
> Later,
>
> Euman
> euman at bellsouth.net
>
>
>
>
>
>
3. Re: Threads......
Hi "euman",
> Threads are impossible for me useing strictly Euphoria.
That's a pity.
> -- start threads
> hThread1 = call_back(routine_id("Thread1"))
> hThread2 = call_back(routine_id("Thread2"))
>
> hThread1 = c_func(xCreateThread,{NULL, NULL, hThread1, NULL,
> NORMAL_PRIORITY_CLASS, thread1})
> hThread2 = c_func(xCreateThread,{NULL, NULL, hThread2, NULL,
> NORMAL_PRIORITY_CLASS, thread2})
>
> The call_back address is not a *real* proc address
Why not? What is it then? What is it missing?
> I will have to create a .dll for use, useing Masm32 or Borlands C++.
> I need to learn a few things to do this so no-one hold their breathe.
Yeah, it a big learning curve. Threads alone are difficult enough without
trying Microsoft's implementation of them.
> Something like this would be more valuable than namespace
> in my opinion.
Why?
I would love to be able to use threads, but I wouldn't need them very often.
They are complex to control properly and can even cause performance
degradation trying to synchronise things. Deadlocks are also possible.
Whereas namespace has an effect on most non-small programs.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
4. Re: Threads......
- Posted by gertie at ad-tek.net
Jul 05, 2001
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
> Jeff
> ----- Original Message -----
> From: <euman at bellsouth.net>
> To: "EUforum" <EUforum at topica.com>
> Sent: Thursday, July 05, 2001 10:18 PM
> Subject: Threads......
>
>
> >
> >
> > Threads are impossible for me useing strictly Euphoria.
> >
> > -- start threads
> > hThread1 = call_back(routine_id("Thread1"))
> > hThread2 = call_back(routine_id("Thread2"))
> >
> > hThread1 = c_func(xCreateThread,{NULL, NULL, hThread1, NULL,
> > NORMAL_PRIORITY_CLASS, thread1})
> > hThread2 = c_func(xCreateThread,{NULL, NULL, hThread2, NULL,
> > NORMAL_PRIORITY_CLASS, thread2})
> >
> > The call_back address is not a *real* proc address
> >
> > I will have to create a .dll for use, useing Masm32 or Borlands C++.
> > I need to learn a few things to do this so no-one hold their breathe.
> >
> > Something like this would be more valuable than namespace
> > in my opinion.
> >
> > Later,
> >
> > Euman
> > euman at bellsouth.net
> >
> >
> >
> >
> >
> >
>
>
>
>
>
5. Re: Threads......
- Posted by euman at bellsouth.net
Jul 05, 2001
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
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
>
> > Jeff
> > ----- Original Message -----
> > From: <euman at bellsouth.net>
> > To: "EUforum" <EUforum at topica.com>
> > Sent: Thursday, July 05, 2001 10:18 PM
> > Subject: Threads......
> >
> >
> > >
> > >
> > > Threads are impossible for me useing strictly Euphoria.
> > >
> > > -- start threads
> > > hThread1 = call_back(routine_id("Thread1"))
> > > hThread2 = call_back(routine_id("Thread2"))
> > >
> > > hThread1 = c_func(xCreateThread,{NULL, NULL, hThread1, NULL,
> > > NORMAL_PRIORITY_CLASS, thread1})
> > > hThread2 = c_func(xCreateThread,{NULL, NULL, hThread2, NULL,
> > > NORMAL_PRIORITY_CLASS, thread2})
> > >
> > > The call_back address is not a *real* proc address
> > >
> > > I will have to create a .dll for use, useing Masm32 or Borlands C++.
> > > I need to learn a few things to do this so no-one hold their breathe.
> > >
> > > Something like this would be more valuable than namespace
> > > in my opinion.
> > >
> > > Later,
> > >
> > > Euman
> > > euman at bellsouth.net
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
>
6. Re: Threads......
- Posted by gertie at ad-tek.net
Jul 05, 2001
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
> >
> > > Jeff
> > > ----- Original Message -----
> > > From: <euman at bellsouth.net>
> > > To: "EUforum" <EUforum at topica.com>
> > > Sent: Thursday, July 05, 2001 10:18 PM
> > > Subject: Threads......
> > >
> > >
> > > >
> > > >
> > > > Threads are impossible for me useing strictly Euphoria.
> > > >
> > > > -- start threads
> > > > hThread1 = call_back(routine_id("Thread1"))
> > > > hThread2 = call_back(routine_id("Thread2"))
> > > >
> > > > hThread1 = c_func(xCreateThread,{NULL, NULL, hThread1, NULL,
> > > > NORMAL_PRIORITY_CLASS, thread1})
> > > > hThread2 = c_func(xCreateThread,{NULL, NULL, hThread2, NULL,
> > > > NORMAL_PRIORITY_CLASS, thread2})
> > > >
> > > > The call_back address is not a *real* proc address
> > > >
> > > > I will have to create a .dll for use, useing Masm32 or Borlands C++.
> > > > I need to learn a few things to do this so no-one hold their breathe.
> > > >
> > > > Something like this would be more valuable than namespace
> > > > in my opinion.
> > > >
> > > > Later,
> > > >
> > > > Euman
> > > > euman at bellsouth.net
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
7. Re: Threads......
- Posted by irvm at ellijay.com
Jul 06, 2001
On Friday 06 July 2001 08:51, SR.Williamson wrote:
> 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?
You don't really need threads to do what you have described. Semaphores,
probably, so one program would know when a program it called was finished.
Shared variables would be nice also, but files can often be substituted.
See Pete Eberlein's remote procedure calls in the archives for an example.
Threads, at least in my understanding, are most useful when you want to
use the same code to do several tasks, and you would prefer that the tasks
not be done sequentially.
A prime example would be downloading files or pages from the internet.
The routine which can download one file, can download any file. Without
threads, you'd have to wait for the first one to finish before the second
could begin. If there are delays in the first download, you're just wasting
time waiting, time which could be used by the same routine to download the
other file(s) - if you were able to thread your code.
In this example, you don't really care which of the three spawned treads
finishes first. In other cases, keeping track of that might be very important.
In addition, every 'instance' of the thread must have it's own set of
variables, (which file am I downloading, how far along am i, what to do
in case of error, etc.) All non-trivial stuff.
Regards,
Irv
