1. Threads......
- Posted by euman at bellsouth.net Jul 05, 2001
- 409 views
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......
- Posted by Jeffrey Fielding <jjprog at earthlink.net> Jul 05, 2001
- 407 views
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......
- Posted by Derek Parnell <ddparnell at bigpond.com> Jul 05, 2001
- 396 views
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
- 399 views
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
- 405 views
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
- 402 views
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
- 418 views
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