1. RE: Threads......
- Posted by Bernie Ryan <xotron at localnet.com> Jul 05, 2001
- 394 views
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......
- Posted by sephiroth _ <euman2376 at yahoo.com> Jul 05, 2001
- 371 views
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......
- Posted by "SR.Williamson" <writeneu at hotmail.com> Jul 06, 2001
- 396 views
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
- 398 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
5. RE: Threads......
- Posted by sephiroth _ <euman2376 at yahoo.com> Jul 06, 2001
- 377 views
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)