1. Multitasking Preview Release
- Posted by Robert Craig <rds at RapidEuphoria.com> Sep 20, 2005
- 604 views
I've posted, as a User Contribution, the 2.5 PD source interpreter modified for multitasking. It supports several multitasking API calls. It has a scheduler built-in to the interpreter. Instead of the traditional single call stack, each task has its own call-stack, program counter (i.e. current statement) and private variables. By executing task_yield() at any place its code, and at any level of subroutine call, a task can yield control to the scheduler, and get it back later. See readme.txt for more info. Included is a modified version of Language War, converted to use the new API. I also created a graphical (DOS) demo that shows 4 different sorting algorithms running in parallel. For the PD and official interpreters, a major change was/is required in the way that private data is saved/restored. The Translator should be simpler. I don't expect most programs will use multitasking, but it's a lot of fun where appropriate. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
2. Re: Multitasking Preview Release
- Posted by Vincent <darkvincentdude at yahoo.com> Sep 20, 2005
- 574 views
Robert Craig wrote: > > I've posted, as a User Contribution, the 2.5 PD source interpreter > modified for multitasking. > > It supports several multitasking API calls. > It has a scheduler built-in to the interpreter. > > Instead of the traditional single call stack, > each task has its own call-stack, program counter (i.e. current statement) > and private variables. > > By executing task_yield() at any place its code, and at any level of > subroutine call, a task can yield control to the scheduler, and get it > back later. See readme.txt for more info. > > Included is a modified version of Language War, converted to use the > new API. I also created a graphical (DOS) demo that shows 4 different > sorting algorithms running in parallel. > > For the PD and official interpreters, a major change was/is required in > the way that private data is saved/restored. The Translator should be > simpler. > > I don't expect most programs will use multitasking, but it's a > lot of fun where appropriate. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > Cool Rob, I translated & compiled the source, and everything seems to run well. According to the documentation, the six tasking routines are implemented internally. That saves overhead from needing to include files, or time wrapping machine_func()/machine_proc() operations. With that said, I must ask why didnt just implement all the Euphoria routines completely internally from the start? That way there wouldnt be a need for include files for the Euphoria standard library, or having machine_proc(), or machine_func() routines. It's seems sort of like a mixed mess now, that could of been avoided. Regards, Vincent ---------------------------------------------- ___ __________ ___ /__/\ /__________\ |\ _\ \::\'\ //::::::::::\\ |'|::| \::\'\ //:::_::::_:::\\ |'|::| \::\'\ //::/ |::| \::\\ |'|::| \::\'\ //::/ |::| \::\\|'|::| \::\'\__//::/ |::| \::\|'|::| \::\','/::/ |::| \::\\|::| \::\_/::/ |::| \::\|::| \::,::/ |::| \:::::| \___/ |__| \____| .``. ',,'
3. Re: Multitasking Preview Release
- Posted by Al Getz <Xaxo at aol.com> Sep 20, 2005
- 563 views
- Last edited Sep 21, 2005
Hi Rob, Looks interesting...just two questions... 1. Will it allow a task to be interrupted when doing disk i/o? 2. Does it work using Windows also? Take care, Al And, good luck with your Euphoria programming! My bumper sticker: "I brake for LED's"
4. Re: Multitasking Preview Release
- Posted by Robert Craig <rds at RapidEuphoria.com> Sep 20, 2005
- 543 views
- Last edited Sep 21, 2005
Vincent wrote: > Cool Rob, I translated & compiled the source, and everything seems to run > well. According > to the documentation, the six tasking routines are implemented internally. > That saves overhead > from needing to include files, or time wrapping machine_func()/machine_proc() > operations. > > With that said, I must ask why didnt just implement all the Euphoria routines > completely > internally from the start? That way there wouldnt be a need for include files > for the > Euphoria standard library, or having machine_proc(), or machine_func() > routines. It's > seems sort of like a mixed mess now, that could of been avoided. It's a judgement call whether something should be implemented as Euphoria code in an include file, or as a machine_proc/func special call, or as a built-in routine. Most things are not built-in because I don't want to have hundreds of predefined symbols, many of them rarely used, using up space in the symbol table, and forced on people who might want to use those nice names for some other purpose. Overhead is not always important. Some routines are rarely used in time-critical operations, and some are so costly to run that saving a bit of overhead in calling them would be meaningless. Some things like generic sort() are written in Euphoria because they manipulate Euphoria values more easily and without losing much speed compared to an internal C implementation. I haven't heard of anyone tearing their hair out over the speed of sort() in a real program. I especially wanted task_yield() to be built-in, because if it wasn't, people would feel more pressure to move it out of loops. They might call it once per loop, rather than once per iteration. Any overhead would make for less smooth multitasking. This form of multitasking is as fundamental as subroutine calling. It really should be in the guts of the interpreter. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
5. Re: Multitasking Preview Release
- Posted by Robert Craig <rds at RapidEuphoria.com> Sep 20, 2005
- 549 views
- Last edited Sep 21, 2005
Al Getz wrote: > Looks interesting...just two questions... > > 1. Will it allow a task to be interrupted when doing disk i/o? You would need to use asynchronous I/O. There are API calls in Windows and Linux/FreeBSD that let you initiate a chunk of I/O, and then check periodically to see when it has finished. You can do other stuff while the I/O is happening. So you might have a task in charge of reading in a large (or slow) block of data. It could yield after starting the I/O, and get control back periodically from the scheduler so it can check if the I/O is finished. Another, less fancy, approach would be to give a task the job of reading in a file. It could maybe read one line at a time and then yield control to the scheduler. For instance an editor could be up and running quickly, and handling commands, while a background task is still reading in the file. You'd have to be careful of course. Also, in this day and age, the file would have to be huge for this to be worthwhile. > 2. Does it work using Windows also? Yes it does. You might have a task that performs doEvents() while other tasks are doing other processing. I didn't make a Windows demo because I thought the DOS demos would show the tasking primitives more clearly. I, or maybe someone else, should develop nice Windows and Linux/FreeBSD demos. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
6. Re: Multitasking Preview Release
- Posted by Al Getz <Xaxo at aol.com> Sep 20, 2005
- 548 views
- Last edited Sep 21, 2005
Robert Craig wrote: > > Al Getz wrote: > > Looks interesting...just two questions... > > > 2. Does it work using Windows also? > > Yes it does. > You might have a task that performs doEvents() while other > tasks are doing other processing. I didn't make a Windows demo > because I thought the DOS demos would show the tasking primitives > more clearly. I, or maybe someone else, should develop nice > Windows and Linux/FreeBSD demos. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > Hi again Rob, Ok great, i'll give it a shot tomorrow some time. I'll try to create a demo similar to the "Virtual Thread Manager 02" demo using Windows. All it has to do is save (or read) a very large file while still allowing the user to keep control over gui stuff like the mouse, menu items, etc. I want to become familiar with the function calls anyway so i can understand when they will be beneficial to my programs. If it works similar it will be very nice, with tasking built in now :) Take care, Al And, good luck with your Euphoria programming! My bumper sticker: "I brake for LED's"
7. Re: Multitasking Preview Release
- Posted by Jonas Temple <jtemple at yhti.net> Sep 20, 2005
- 563 views
- Last edited Sep 21, 2005
Rob, Will this handle the following (in Windows): * Routine "a" is executed when a user clicks a button * "a" starts task "b" * task "b" calls a routine in a .DLL that extracts information from another computer. Sometimes the answer comes back quickly and sometimes the answer comes back in minutes (i.e. SQL query). For this example, let's say 5 minutes. * user can't wait for answer and wants to cancel the query. I add a button to the window that lets the user cancel the query. User clicks button and I use task_kill() against task "b". Since task "b" is still waiting for the routine in the DLL to return, would taks "b" be cancelled immediately or when the DLL returns control to task "b"? Jonas Temple http://www.yhti.net/~jktemple
8. Re: Multitasking Preview Release
- Posted by Robert Craig <rds at RapidEuphoria.com> Sep 21, 2005
- 567 views
Jonas Temple wrote: > Will this handle the following (in Windows): > > * Routine "a" is executed when a user clicks a button > * "a" starts task "b" > * task "b" calls a routine in a .DLL that extracts information from another > computer. > Sometimes the answer comes back quickly and sometimes the answer comes back > in minutes > (i.e. SQL query). For this example, let's say 5 minutes. > * user can't wait for answer and wants to cancel the query. I add a button to > the > window that lets the user cancel the query. User clicks button and I use > task_kill() > against task "b". > > Since task "b" is still waiting for the routine in the DLL to return, would > taks "b" > be cancelled immediately or when the DLL returns control to task "b"? With cooperative multitasking, task b can't call a routine in a .dll and then wait inside that call, without holding up all the other tasks. What you need is some kind of asynchronous (non-blocking) I/O call, that will let task b return from the call immediately, and then check periodically to see if the I/O is complete. You could set up task b to check, say, every 2 or 3 seconds to see if the I/O is complete. While it's doing that, other tasks could handle the user interface, and any other processing that you want to do in parallel with task b. If the user wants to stop the I/O, you could let task b know via a global variable that it should quit, or you could call task_kill() on task b to force it to stop the periodic checking. In general, when task A kills task B using task_kill(), task B will be stopped on a task_yield() statement. Task B will not run again, and it's call stack and private variables will be freed up. If task A kills itself by calling task_kill(task_self()), task A will actually continue until it hits a task_yield() statement, then it's game over for task A. Tasks also die if/when their procedure returns. Something that's not clear from the docs (I'll fix it), is that each program has an initial task that's created automatically. It can be scheduled like the other tasks that you explicitly create. Its task id is 0. Until the initial task yields, no other task can run. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
9. Re: Multitasking Preview Release
- Posted by codepilot Gmail Account <codepilot at gmail.com> Sep 21, 2005
- 553 views
Now you can use blocking C/dll calls with the task-switching-euphoria. I used kernel32:Sleep in my example, but it could be used for anything, like wsock32:getaddrinfo or wsock32:gethostbyname to get dns info. Or really slow blocking readfile or anything. http://www.RapidEuphoria.com/uploads/tdll.zip Daniel On 9/20/05, Robert Craig <guest at rapideuphoria.com> wrote: > > > posted by: Robert Craig <rds at RapidEuphoria.com> > > Jonas Temple wrote: > > Will this handle the following (in Windows): > > > > * Routine "a" is executed when a user clicks a button > > * "a" starts task "b" > > * task "b" calls a routine in a .DLL that extracts information from ano= ther computer. > > Sometimes the answer comes back quickly and sometimes the answer comes= back in minutes > > (i.e. SQL query). For this example, let's say 5 minutes. > > * user can't wait for answer and wants to cancel the query. I add a bu= tton to the > > window that lets the user cancel the query. User clicks button and I u= se task_kill() > > against task "b". > > > > Since task "b" is still waiting for the routine in the DLL to return, w= ould taks "b" > > be cancelled immediately or when the DLL returns control to task "b"? > > With cooperative multitasking, task b can't call a routine in a .dll > and then wait inside that call, without holding up all the other tasks. > > What you need is some kind of asynchronous (non-blocking) I/O call, > that will let task b return from the call immediately, and then > check periodically to see if the I/O is complete. You could set up > task b to check, say, every 2 or 3 seconds to see if the I/O is complete. > While it's doing that, other tasks could handle the user interface, > and any other processing that you want to do in parallel with task b. > If the user wants to stop the I/O, you could let task b know via > a global variable that it should quit, or you could call > task_kill() on task b to force it to stop the periodic checking. > > In general, when task A kills task B using task_kill(), > task B will be stopped on a task_yield() statement. Task B will not > run again, and it's call stack and private variables will be freed up. > > If task A kills itself by calling task_kill(task_self()), > task A will actually continue until it hits a task_yield() > statement, then it's game over for task A. > Tasks also die if/when their procedure returns. > > Something that's not clear from the docs (I'll fix it), > is that each program has an initial task that's created > automatically. It can be scheduled like the other tasks that > you explicitly create. Its task id is 0. > Until the initial task yields, no other task can run. > > Regards, > Rob Craig > Rapid Deployment Software > http://www.RapidEuphoria.com > > > >
10. Re: Multitasking Preview Release
- Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 22, 2005
- 568 views
Robert Craig wrote: > Jonas Temple wrote: >> Will this handle the following (in Windows): >> >> * Routine "a" is executed when a user clicks a button >> * "a" starts task "b" >> * task "b" calls a routine in a .DLL that extracts information from another >> computer. >> Sometimes the answer comes back quickly and sometimes the answer comes back >> in minutes >> (i.e. SQL query). For this example, let's say 5 minutes. >> * user can't wait for answer and wants to cancel the query. I add a button >> to the >> window that lets the user cancel the query. User clicks button and I use >> task_kill() >> against task "b". >> >> Since task "b" is still waiting for the routine in the DLL to return, would >> taks "b" >> be cancelled immediately or when the DLL returns control to task "b"? > > With cooperative multitasking, task b can't call a routine in a .dll > and then wait inside that call, without holding up all the other tasks. > > What you need is some kind of asynchronous (non-blocking) I/O call, > that will let task b return from the call immediately, and then > check periodically to see if the I/O is complete. You could set up > task b to check, say, every 2 or 3 seconds to see if the I/O is complete. > While it's doing that, other tasks could handle the user interface, > and any other processing that you want to do in parallel with task b. > If the user wants to stop the I/O, you could let task b know via > a global variable that it should quit, or you could call > task_kill() on task b to force it to stop the periodic checking. <snip> I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, when the DLL reads/writes huge files, obviously Total Commander is not able to update the optical appearance of its main window, until the DLL has finished its work. Can I do something to solve the problem now, without the new multitasking system? Can the new multitasking system help to write "more cooperative" DLLs? TIA, Juergen -- Have you read a good program lately?
11. Re: Multitasking Preview Release
- Posted by codepilot Gmail Account <codepilot at gmail.com> Sep 22, 2005
- 560 views
Get the new TDLL, and use t_func/proc it splits calls into other threads so blocking calls turn into non-blocking. Dan On 9/22/05, Juergen Luethje <j.lue at gmx.de> wrote: > > > Robert Craig wrote: > > > Jonas Temple wrote: > >> Will this handle the following (in Windows): > >> > >> * Routine "a" is executed when a user clicks a button > >> * "a" starts task "b" > >> * task "b" calls a routine in a .DLL that extracts information from an= other computer. > >> Sometimes the answer comes back quickly and sometimes the answer come= s back in minutes > >> (i.e. SQL query). For this example, let's say 5 minutes. > >> * user can't wait for answer and wants to cancel the query. I add a b= utton to the > >> window that lets the user cancel the query. User clicks button and I = use task_kill() > >> against task "b". > >> > >> Since task "b" is still waiting for the routine in the DLL to return, = would taks "b" > >> be cancelled immediately or when the DLL returns control to task "b"? > > > > With cooperative multitasking, task b can't call a routine in a .dll > > and then wait inside that call, without holding up all the other tasks. > > > > What you need is some kind of asynchronous (non-blocking) I/O call, > > that will let task b return from the call immediately, and then > > check periodically to see if the I/O is complete. You could set up > > task b to check, say, every 2 or 3 seconds to see if the I/O is complet= e. > > While it's doing that, other tasks could handle the user interface, > > and any other processing that you want to do in parallel with task b. > > If the user wants to stop the I/O, you could let task b know via > > a global variable that it should quit, or you could call > > task_kill() on task b to force it to stop the periodic checking. > > <snip> > > I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, when > the DLL reads/writes huge files, obviously Total Commander is not able > to update the optical appearance of its main window, until the DLL has > finished its work. > > Can I do something to solve the problem now, without the new > multitasking system? Can the new multitasking system help to write > "more cooperative" DLLs? > > TIA, > Juergen > > -- > Have you read a good program lately? > > > >
12. Re: Multitasking Preview Release
- Posted by Vincent <darkvincentdude at yahoo.com> Sep 22, 2005
- 545 views
- Last edited Sep 23, 2005
codepilot Gmail Account wrote: > > Get the new TDLL, and use t_func/proc it splits calls into other > threads so blocking calls turn into non-blocking. > > Dan > > On 9/22/05, Juergen Luethje <j.lue at gmx.de> wrote: > > > > > > Robert Craig wrote: > > > > > Jonas Temple wrote: > > >> Will this handle the following (in Windows): > > >> > > >> * Routine "a" is executed when a user clicks a button > > >> * "a" starts task "b" > > >> * task "b" calls a routine in a .DLL that extracts information from an= > other computer. > > >> Sometimes the answer comes back quickly and sometimes the answer come= > s back in minutes > > >> (i.e. SQL query). For this example, let's say 5 minutes. > > >> * user can't wait for answer and wants to cancel the query. I add a b= > utton to the > > >> window that lets the user cancel the query. User clicks button and I = > use task_kill() > > >> against task "b". > > >> > > >> Since task "b" is still waiting for the routine in the DLL to return, = > would taks "b" > > >> be cancelled immediately or when the DLL returns control to task "b"? > > > > > > With cooperative multitasking, task b can't call a routine in a .dll > > > and then wait inside that call, without holding up all the other tasks. > > > > > > What you need is some kind of asynchronous (non-blocking) I/O call, > > > that will let task b return from the call immediately, and then > > > check periodically to see if the I/O is complete. You could set up > > > task b to check, say, every 2 or 3 seconds to see if the I/O is complet= > e. > > > While it's doing that, other tasks could handle the user interface, > > > and any other processing that you want to do in parallel with task b. > > > If the user wants to stop the I/O, you could let task b know via > > > a global variable that it should quit, or you could call > > > task_kill() on task b to force it to stop the periodic checking. > > > > <snip> > > > > I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, when > > the DLL reads/writes huge files, obviously Total Commander is not able > > to update the optical appearance of its main window, until the DLL has > > finished its work. > > > > Can I do something to solve the problem now, without the new > > multitasking system? Can the new multitasking system help to write > > "more cooperative" DLLs? > > > > TIA, > > Juergen > > > > -- > > Have you read a good program lately? > > > > Dan, ttest.exw still runs even if I replace define_t_func with define_c_func, t_proc with c_proc, open_tdll with open_dll, and include dll.e not tdll.e It runs 100x slower, and the thread ids count down in single increments, vs random. Do you know what is happening? Regards, Vincent
13. Re: Multitasking Preview Release
- Posted by codepilot Gmail Account <codepilot at gmail.com> Sep 22, 2005
- 579 views
- Last edited Sep 23, 2005
the whole tdll.e library is a replacement for dll.e. The calls to t_proc/t_func actually fork the c-calls into a new thread, and poll to check its completion, while calling task_yield() to let other euphoria threads run. That example uses kernel32:Sleep which is blocking for the time given, say 5 seconds. So 50 threads calling Sleep call run at the same time with t_func/proc because it forks into 50 REAL threads. Now if you use c_func/proc, then it waits for 5 seconds instead of allowing other threads to run, making the waits consecutive instead of parallel. so 50 threads will wait 5seconds*50=250seconds instead of 5seconds threaded. Now kerenl32:Sleep can be ReadFile or TransmitFile or waitmessage or anything that blocks. And if the call doesn't block then you can use c_func probably faster like using opengl calls which complete instanty cause t_func has a little(real little) overhead. Dan On 9/22/05, Vincent <guest at rapideuphoria.com> wrote: > > > posted by: Vincent <darkvincentdude at yahoo.com> > > codepilot Gmail Account wrote: > > > > Get the new TDLL, and use t_func/proc it splits calls into other > > threads so blocking calls turn into non-blocking. > > > > Dan > > > > On 9/22/05, Juergen Luethje <j.lue at gmx.de> wrote: > > > > > > > > > Robert Craig wrote: > > > > > > > Jonas Temple wrote: > > > >> Will this handle the following (in Windows): > > > >> > > > >> * Routine "a" is executed when a user clicks a button > > > >> * "a" starts task "b" > > > >> * task "b" calls a routine in a .DLL that extracts information fro= m an= > > other computer. > > > >> Sometimes the answer comes back quickly and sometimes the answer = come= > > s back in minutes > > > >> (i.e. SQL query). For this example, let's say 5 minutes. > > > >> * user can't wait for answer and wants to cancel the query. I add= a b= > > utton to the > > > >> window that lets the user cancel the query. User clicks button an= d I = > > use task_kill() > > > >> against task "b". > > > >> > > > >> Since task "b" is still waiting for the routine in the DLL to retu= rn, = > > would taks "b" > > > >> be cancelled immediately or when the DLL returns control to task "= b"? > > > > > > > > With cooperative multitasking, task b can't call a routine in a .dl= l > > > > and then wait inside that call, without holding up all the other ta= sks. > > > > > > > > What you need is some kind of asynchronous (non-blocking) I/O call, > > > > that will let task b return from the call immediately, and then > > > > check periodically to see if the I/O is complete. You could set up > > > > task b to check, say, every 2 or 3 seconds to see if the I/O is com= plet= > > e. > > > > While it's doing that, other tasks could handle the user interface, > > > > and any other processing that you want to do in parallel with task = b. > > > > If the user wants to stop the I/O, you could let task b know via > > > > a global variable that it should quit, or you could call > > > > task_kill() on task b to force it to stop the periodic checking. > > > > > > <snip> > > > > > > I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, when > > > the DLL reads/writes huge files, obviously Total Commander is not abl= e > > > to update the optical appearance of its main window, until the DLL ha= s > > > finished its work. > > > > > > Can I do something to solve the problem now, without the new > > > multitasking system? Can the new multitasking system help to write > > > "more cooperative" DLLs? > > > > > > TIA, > > > Juergen > > > > > > -- > > > Have you read a good program lately? > > > > > > > Dan, > > ttest.exw still runs even if I replace define_t_func with define_c_func, = t_proc with c_proc, open_tdll with open_dll, and include dll.e not tdll.e > > It runs 100x slower, and the thread ids count down in single increments, = vs random. Do you know what is happening? > > > Regards, > Vincent > > > >
14. Re: Multitasking Preview Release
- Posted by Robert Craig <rds at RapidEuphoria.com> Sep 23, 2005
- 556 views
Juergen Luethje wrote: > I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, when > the DLL reads/writes huge files, obviously Total Commander is not able > to update the optical appearance of its main window, until the DLL has > finished its work. > > Can I do something to solve the problem now, without the new > multitasking system? Can the new multitasking system help to write > "more cooperative" DLLs? You either need some kind of non-blocking I/O, or you need TDLL (Daniel Kluss) which creates a new O/S thread and returns immediately. I assume it will be safe to run the Euphoria interpreter in one O/S thread, and some DLL code in another. I'm not sure yet how multitasking is going to work with Euphoria-coded DLLs. Main Euphoria programs and Euphoria-coded DLLs don't even share the same routine ids. Probably a Euphoria DLL could run its own tasks independent from the main program. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
15. Re: Multitasking Preview Release
- Posted by codepilot Gmail Account <codepilot at gmail.com> Sep 23, 2005
- 553 views
with tdll you could have a situation where there is two enterences into a euphoria dll so I would use c_func for anything thats a euphoria dll. (ROB) Can two or more threads run on euphoria dlls without crashing, cause I really doubt it? Now If you really wanted to you should use tdll in that euphoria code that made the dll and you wouldn't have to worry about it blocking. Maybe later, small well-thought-out steps, we don't want to trip. Dan On 9/22/05, Robert Craig <guest at rapideuphoria.com> wrote: > > > posted by: Robert Craig <rds at RapidEuphoria.com> > > Juergen Luethje wrote: > > I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, when > > the DLL reads/writes huge files, obviously Total Commander is not able > > to update the optical appearance of its main window, until the DLL has > > finished its work. > > > > Can I do something to solve the problem now, without the new > > multitasking system? Can the new multitasking system help to write > > "more cooperative" DLLs? > > You either need some kind of non-blocking I/O, or you need > TDLL (Daniel Kluss) which creates a new O/S thread and returns > immediately. I assume it will be safe to run the Euphoria interpreter > in one O/S thread, and some DLL code in another. > > I'm not sure yet how multitasking is going to work with > Euphoria-coded DLLs. Main Euphoria programs and Euphoria-coded DLLs > don't even share the same routine ids. Probably a Euphoria DLL > could run its own tasks independent from the main program. > > Regards, > Rob Craig > Rapid Deployment Software > http://www.RapidEuphoria.com > > > >
16. Re: Multitasking Preview Release
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Sep 23, 2005
- 550 views
codepilot Gmail Account wrote: > > with tdll you could have a situation where there is two enterences > into a euphoria dll so I would use c_func for anything thats a > euphoria dll. > (ROB) Can two or more threads run on euphoria dlls without crashing, > cause I really doubt it? > Now If you really wanted to you should use tdll in that euphoria code > that made the dll and you wouldn't have to worry about it blocking. > Maybe later, small well-thought-out steps, we don't want to trip. > I did some testing of my own. As long as you call different routines, it seems to be OK. But my tests were very simple, and if you end up accessing any of the same data, you could be in trouble. Best to avoid, I think. Matt Lewis
17. Re: Multitasking Preview Release
- Posted by Vincent <darkvincentdude at yahoo.com> Sep 23, 2005
- 560 views
codepilot Gmail Account wrote: > > with tdll you could have a situation where there is two enterences > into a euphoria dll so I would use c_func for anything thats a > euphoria dll. > (ROB) Can two or more threads run on euphoria dlls without crashing, > cause I really doubt it? > Now If you really wanted to you should use tdll in that euphoria code > that made the dll and you wouldn't have to worry about it blocking. > Maybe later, small well-thought-out steps, we don't want to trip. > > Dan > > On 9/22/05, Robert Craig <guest at rapideuphoria.com> wrote: > > > > > > posted by: Robert Craig <rds at RapidEuphoria.com> > > > > Juergen Luethje wrote: > > > I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, when > > > the DLL reads/writes huge files, obviously Total Commander is not able > > > to update the optical appearance of its main window, until the DLL has > > > finished its work. > > > > > > Can I do something to solve the problem now, without the new > > > multitasking system? Can the new multitasking system help to write > > > "more cooperative" DLLs? > > > > You either need some kind of non-blocking I/O, or you need > > TDLL (Daniel Kluss) which creates a new O/S thread and returns > > immediately. I assume it will be safe to run the Euphoria interpreter > > in one O/S thread, and some DLL code in another. > > > > I'm not sure yet how multitasking is going to work with > > Euphoria-coded DLLs. Main Euphoria programs and Euphoria-coded DLLs > > don't even share the same routine ids. Probably a Euphoria DLL > > could run its own tasks independent from the main program. > > > > Regards, > > Rob Craig > > Rapid Deployment Software > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > > > > Cool little library you got there Dan, can you add support for the "cdcel" calling convention, and port it for Linux/FreeBSD? Because I have "zero" understanding of machine level coding with Euphoria, I cannot finish this myself. Nevertheless this little library could be very useful to me in various cases, and I'm ready to vote for it upon completion.. Regards, Vincent ---------------------------------------------- ___ __________ ___ /__/\ /__________\ |\ _\ \::\'\ //::::::::::\\ |'|::| \::\'\ //:::_::::_:::\\ |'|::| \::\'\ //::/ |::| \::\\ |'|::| \::\'\ //::/ |::| \::\\|'|::| \::\'\__//::/ |::| \::\|'|::| \::\','/::/ |::| \::\\|::| \::\_/::/ |::| \::\|::| \::,::/ |::| \:::::| \___/ |__| \____| .``. ',,'
18. Re: Multitasking Preview Release
- Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 23, 2005
- 547 views
codepilot Gmail Account wrote: > On 9/22/05, Juergen Luethje wrote: <snip> >> I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, when >> the DLL reads/writes huge files, obviously Total Commander is not able >> to update the optical appearance of its main window, until the DLL has >> finished its work. >> >> Can I do something to solve the problem now, without the new >> multitasking system? Can the new multitasking system help to write >> "more cooperative" DLLs? > > Get the new TDLL, and use t_func/proc it splits calls into other > threads so blocking calls turn into non-blocking. Thanks Daniel, TDLL is interesting. However, I don't see how it can help to solve the problem. In a reply to Vincent you wrote: "the whole tdll.e library is a replacement for dll.e" My Eu code does not use 'dll.e'. The code is translated and compiled to a DLL itself. Of course I have no influence on the way how Total Commander calls the code in my Eu DLL. Am I overlooking something? Regards, Juergen -- Have you read a good program lately?
19. Re: Multitasking Preview Release
- Posted by codepilot Gmail Account <codepilot at gmail.com> Sep 23, 2005
- 549 views
What part of you eucode is slow? Could you give me a general outline of how the program works? Daniel On 9/23/05, Juergen Luethje <j.lue at gmx.de> wrote: > > > codepilot Gmail Account wrote: > > > On 9/22/05, Juergen Luethje wrote: > > <snip> > > >> I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, when > >> the DLL reads/writes huge files, obviously Total Commander is not able > >> to update the optical appearance of its main window, until the DLL has > >> finished its work. > >> > >> Can I do something to solve the problem now, without the new > >> multitasking system? Can the new multitasking system help to write > >> "more cooperative" DLLs? > > > > Get the new TDLL, and use t_func/proc it splits calls into other > > threads so blocking calls turn into non-blocking. > > Thanks Daniel, TDLL is interesting. > However, I don't see how it can help to solve the problem. > In a reply to Vincent you wrote: > > "the whole tdll.e library is a replacement for dll.e" > > My Eu code does not use 'dll.e'. The code is translated and compiled > to a DLL itself. Of course I have no influence on the way how > Total Commander calls the code in my Eu DLL. > Am I overlooking something? > > Regards, > Juergen > > -- > Have you read a good program lately? > > > >
20. Re: Multitasking Preview Release
- Posted by codepilot Gmail Account <codepilot at gmail.com> Sep 23, 2005
- 577 views
I can port it for assembly and cdcel, and probably linux/freebsd, but how do you call linux/freebsd and where are the manuals for the api's so I can find the threading support? Dan On 9/22/05, Vincent <guest at rapideuphoria.com> wrote: > > > posted by: Vincent <darkvincentdude at yahoo.com> > > codepilot Gmail Account wrote: > > > > with tdll you could have a situation where there is two enterences > > into a euphoria dll so I would use c_func for anything thats a > > euphoria dll. > > (ROB) Can two or more threads run on euphoria dlls without crashing, > > cause I really doubt it? > > Now If you really wanted to you should use tdll in that euphoria code > > that made the dll and you wouldn't have to worry about it blocking. > > Maybe later, small well-thought-out steps, we don't want to trip. > > > > Dan > > > > On 9/22/05, Robert Craig <guest at rapideuphoria.com> wrote: > > > > > > > > > posted by: Robert Craig <rds at RapidEuphoria.com> > > > > > > Juergen Luethje wrote: > > > > I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, wh= en > > > > the DLL reads/writes huge files, obviously Total Commander is not a= ble > > > > to update the optical appearance of its main window, until the DLL = has > > > > finished its work. > > > > > > > > Can I do something to solve the problem now, without the new > > > > multitasking system? Can the new multitasking system help to write > > > > "more cooperative" DLLs? > > > > > > You either need some kind of non-blocking I/O, or you need > > > TDLL (Daniel Kluss) which creates a new O/S thread and returns > > > immediately. I assume it will be safe to run the Euphoria interpreter > > > in one O/S thread, and some DLL code in another. > > > > > > I'm not sure yet how multitasking is going to work with > > > Euphoria-coded DLLs. Main Euphoria programs and Euphoria-coded DLLs > > > don't even share the same routine ids. Probably a Euphoria DLL > > > could run its own tasks independent from the main program. > > > > > > Regards, > > > Rob Craig > > > Rapid Deployment Software > > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.c= om</a> > > > > > > > Cool little library you got there Dan, can you add support for the "cdcel= " calling convention, and port it for Linux/FreeBSD? Because I have "zero" = understanding of machine level coding with Euphoria, I cannot finish this m= yself. Nevertheless this little library could be very useful to me in vario= us cases, and I'm ready to vote for it upon completion.. > > > Regards, > Vincent > > ---------------------------------------------- > ___ __________ ___ > /__/\ /__________\ |\ _\ > \::\'\ //::::::::::\\ |'|::| > \::\'\ //:::_::::_:::\\ |'|::| > \::\'\ //::/ |::| \::\\ |'|::| > \::\'\ //::/ |::| \::\\|'|::| > \::\'\__//::/ |::| \::\|'|::| > \::\','/::/ |::| \::\\|::| > \::\_/::/ |::| \::\|::| > \::,::/ |::| \:::::| > \___/ |__| \____| > > .``. > ',,' > > > >
21. Re: Multitasking Preview Release
- Posted by codepilot Gmail Account <codepilot at gmail.com> Sep 23, 2005
- 553 views
dll = machine_func( 50, "" ), fork_ = machine_func(51, {dll, "fork", {}, C_INT}), fork is like creathread what is like getprocaddress, and loadlibrary? Daniel On 9/23/05, codepilot Gmail Account <codepilot at gmail.com> wrote: > > I can port it for assembly and cdcel, and probably linux/freebsd, but > how do you call linux/freebsd and where are the manuals for the api's > so I can find the threading support? > Dan > > On 9/22/05, Vincent <guest at rapideuphoria.com> wrote: > > > > > > posted by: Vincent <darkvincentdude at yahoo.com> > > > > codepilot Gmail Account wrote: > > > > > > with tdll you could have a situation where there is two enterences > > > into a euphoria dll so I would use c_func for anything thats a > > > euphoria dll. > > > (ROB) Can two or more threads run on euphoria dlls without crashing, > > > cause I really doubt it? > > > Now If you really wanted to you should use tdll in that euphoria code > > > that made the dll and you wouldn't have to worry about it blocking. > > > Maybe later, small well-thought-out steps, we don't want to trip. > > > > > > Dan > > > > > > On 9/22/05, Robert Craig <guest at rapideuphoria.com> wrote: > > > > > > > > > > > > posted by: Robert Craig <rds at RapidEuphoria.com> > > > > > > > > Juergen Luethje wrote: > > > > > I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, = when > > > > > the DLL reads/writes huge files, obviously Total Commander is not= able > > > > > to update the optical appearance of its main window, until the DL= L has > > > > > finished its work. > > > > > > > > > > Can I do something to solve the problem now, without the new > > > > > multitasking system? Can the new multitasking system help to writ= e > > > > > "more cooperative" DLLs? > > > > > > > > You either need some kind of non-blocking I/O, or you need > > > > TDLL (Daniel Kluss) which creates a new O/S thread and returns > > > > immediately. I assume it will be safe to run the Euphoria interpret= er > > > > in one O/S thread, and some DLL code in another. > > > > > > > > I'm not sure yet how multitasking is going to work with > > > > Euphoria-coded DLLs. Main Euphoria programs and Euphoria-coded DLLs > > > > don't even share the same routine ids. Probably a Euphoria DLL > > > > could run its own tasks independent from the main program. > > > > > > > > Regards, > > > > Rob Craig > > > > Rapid Deployment Software > > > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria= .com</a> > > > > > > > > > > Cool little library you got there Dan, can you add support for the "cdc= el" calling convention, and port it for Linux/FreeBSD? Because I have "zero= " understanding of machine level coding with Euphoria, I cannot finish this= myself. Nevertheless this little library could be very useful to me in var= ious cases, and I'm ready to vote for it upon completion.. > > > > > > Regards, > > Vincent > > > > ---------------------------------------------- > > ___ __________ ___ > > /__/\ /__________\ |\ _\ > > \::\'\ //::::::::::\\ |'|::| > > \::\'\ //:::_::::_:::\\ |'|::| > > \::\'\ //::/ |::| \::\\ |'|::| > > \::\'\ //::/ |::| \::\\|'|::| > > \::\'\__//::/ |::| \::\|'|::| > > \::\','/::/ |::| \::\\|::| > > \::\_/::/ |::| \::\|::| > > \::,::/ |::| \:::::| > > \___/ |__| \____| > > > > .``. > > ',,' > > > >
22. Re: Multitasking Preview Release
- Posted by codepilot Gmail Account <codepilot at gmail.com> Sep 23, 2005
- 560 views
fork=creathread query_module=getprocaddress uselib=loadlibrary am I correct, also I don't actually have a nix box so I can test anything. Dan > > Daniel > > > On 9/23/05, codepilot Gmail Account <codepilot at gmail.com> wrote: > > > > I can port it for assembly and cdcel, and probably linux/freebsd, but > > how do you call linux/freebsd and where are the manuals for the api's > > so I can find the threading support? > > Dan > > > > On 9/22/05, Vincent <guest at rapideuphoria.com> wrote: > > > > > > > > > posted by: Vincent <darkvincentdude at yahoo.com> > > > > > > codepilot Gmail Account wrote: > > > > > > > > with tdll you could have a situation where there is two enterences > > > > into a euphoria dll so I would use c_func for anything thats a > > > > euphoria dll. > > > > (ROB) Can two or more threads run on euphoria dlls without crashing= , > > > > cause I really doubt it? > > > > Now If you really wanted to you should use tdll in that euphoria co= de > > > > that made the dll and you wouldn't have to worry about it blocking. > > > > Maybe later, small well-thought-out steps, we don't want to trip. > > > > > > > > Dan > > > > > > > > On 9/22/05, Robert Craig <guest at rapideuphoria.com> wrote: > > > > > > > > > > > > > > > posted by: Robert Craig <rds at RapidEuphoria.com> > > > > > > > > > > Juergen Luethje wrote: > > > > > > I wrote a plugin (a Windows DLL) for Total Commander. Sometimes= , when > > > > > > the DLL reads/writes huge files, obviously Total Commander is n= ot able > > > > > > to update the optical appearance of its main window, until the = DLL has > > > > > > finished its work. > > > > > > > > > > > > Can I do something to solve the problem now, without the new > > > > > > multitasking system? Can the new multitasking system help to wr= ite > > > > > > "more cooperative" DLLs? > > > > > > > > > > You either need some kind of non-blocking I/O, or you need > > > > > TDLL (Daniel Kluss) which creates a new O/S thread and returns > > > > > immediately. I assume it will be safe to run the Euphoria interpr= eter > > > > > in one O/S thread, and some DLL code in another. > > > > > > > > > > I'm not sure yet how multitasking is going to work with > > > > > Euphoria-coded DLLs. Main Euphoria programs and Euphoria-coded DL= Ls > > > > > don't even share the same routine ids. Probably a Euphoria DLL > > > > > could run its own tasks independent from the main program. > > > > > > > > > > Regards, > > > > > Rob Craig > > > > > Rapid Deployment Software > > > > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphor= ia.com</a> > > > > > > > > > > > > > Cool little library you got there Dan, can you add support for the "c= dcel" calling convention, and port it for Linux/FreeBSD? Because I have "ze= ro" understanding of machine level coding with Euphoria, I cannot finish th= is myself. Nevertheless this little library could be very useful to me in v= arious cases, and I'm ready to vote for it upon completion.. > > > > > > > > > Regards, > > > Vincent > > > > > > ---------------------------------------------- > > > ___ __________ ___ > > > /__/\ /__________\ |\ _\ > > > \::\'\ //::::::::::\\ |'|::| > > > \::\'\ //:::_::::_:::\\ |'|::| > > > \::\'\ //::/ |::| \::\\ |'|::| > > > \::\'\ //::/ |::| \::\\|'|::| > > > \::\'\__//::/ |::| \::\|'|::| > > > \::\','/::/ |::| \::\\|::| > > > \::\_/::/ |::| \::\|::| > > > \::,::/ |::| \:::::| > > > \___/ |__| \____| > > > > > > .``. > > > ',,' > > > > > >
23. Re: Multitasking Preview Release
- Posted by codepilot Gmail Account <codepilot at gmail.com> Sep 23, 2005
- 552 views
- Last edited Sep 24, 2005
I added full support for assembly and cdecl, but linux/freebsd is still beyond me for the moment, I have no linux or freebsd box. Could someone else do that? http://www.RapidEuphoria.com/uploads/tdll2.zip Dan On 9/23/05, codepilot Gmail Account <codepilot at gmail.com> wrote: > > I can port it for assembly and cdcel, and probably linux/freebsd, but > how do you call linux/freebsd and where are the manuals for the api's > so I can find the threading support? > Dan > > On 9/22/05, Vincent <guest at rapideuphoria.com> wrote: > > > > > > posted by: Vincent <darkvincentdude at yahoo.com> > > > > codepilot Gmail Account wrote: > > > > > > with tdll you could have a situation where there is two enterences > > > into a euphoria dll so I would use c_func for anything thats a > > > euphoria dll. > > > (ROB) Can two or more threads run on euphoria dlls without crashing, > > > cause I really doubt it? > > > Now If you really wanted to you should use tdll in that euphoria code > > > that made the dll and you wouldn't have to worry about it blocking. > > > Maybe later, small well-thought-out steps, we don't want to trip. > > > > > > Dan > > > > > > On 9/22/05, Robert Craig <guest at rapideuphoria.com> wrote: > > > > > > > > > > > > posted by: Robert Craig <rds at RapidEuphoria.com> > > > > > > > > Juergen Luethje wrote: > > > > > I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, = when > > > > > the DLL reads/writes huge files, obviously Total Commander is not= able > > > > > to update the optical appearance of its main window, until the DL= L has > > > > > finished its work. > > > > > > > > > > Can I do something to solve the problem now, without the new > > > > > multitasking system? Can the new multitasking system help to writ= e > > > > > "more cooperative" DLLs? > > > > > > > > You either need some kind of non-blocking I/O, or you need > > > > TDLL (Daniel Kluss) which creates a new O/S thread and returns > > > > immediately. I assume it will be safe to run the Euphoria interpret= er > > > > in one O/S thread, and some DLL code in another. > > > > > > > > I'm not sure yet how multitasking is going to work with > > > > Euphoria-coded DLLs. Main Euphoria programs and Euphoria-coded DLLs > > > > don't even share the same routine ids. Probably a Euphoria DLL > > > > could run its own tasks independent from the main program. > > > > > > > > Regards, > > > > Rob Craig > > > > Rapid Deployment Software > > > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria= .com</a> > > > > > > > > > > Cool little library you got there Dan, can you add support for the "cdc= el" calling convention, and port it for Linux/FreeBSD? Because I have "zero= " understanding of machine level coding with Euphoria, I cannot finish this= myself. Nevertheless this little library could be very useful to me in var= ious cases, and I'm ready to vote for it upon completion.. > > > > > > Regards, > > Vincent > > > > ---------------------------------------------- > > ___ __________ ___ > > /__/\ /__________\ |\ _\ > > \::\'\ //::::::::::\\ |'|::| > > \::\'\ //:::_::::_:::\\ |'|::| > > \::\'\ //::/ |::| \::\\ |'|::| > > \::\'\ //::/ |::| \::\\|'|::| > > \::\'\__//::/ |::| \::\|'|::| > > \::\','/::/ |::| \::\\|::| > > \::\_/::/ |::| \::\|::| > > \::,::/ |::| \:::::| > > \___/ |__| \____| > > > > .``. > > ',,' > > > >
24. Re: Multitasking Preview Release
- Posted by Ed Davis <ed_davis2 at yahoo.com> Sep 23, 2005
- 552 views
- Last edited Sep 24, 2005
codepilot at gmail.com wrote: >I added full support for assembly and cdecl, but linux/freebsd is >still beyond me for the moment, I have no linux or freebsd box. If you are running XP, get colinux (colinux.org). It runs Linux in a Window under XP. It is great for dabbling with Linux, without having to repartition or get another machine.
25. Re: Multitasking Preview Release
- Posted by codepilot Gmail Account <codepilot at gmail.com> Sep 23, 2005
- 554 views
- Last edited Sep 24, 2005
I will try that, and yup you caught me, I'm running XP. Dan On 9/23/05, Ed Davis <guest at rapideuphoria.com> wrote: > > > posted by: Ed Davis <ed_davis2 at yahoo.com> > > codepilot at gmail.com wrote: > > >I added full support for assembly and cdecl, but linux/freebsd is > >still beyond me for the moment, I have no linux or freebsd box. > > If you are running XP, get colinux (colinux.org). It runs Linux in a > Window under XP. It is great for dabbling with Linux, without having > to repartition or get another machine. > > > >
26. Re: Multitasking Preview Release
- Posted by Vincent <darkvincentdude at yahoo.com> Sep 24, 2005
- 544 views
codepilot Gmail Account wrote: > > I added full support for assembly and cdecl, but linux/freebsd is > still beyond me for the moment, I have no linux or freebsd box. Could > someone else do that? > I found extensive API documentation on the POSIX thread library and documetation for an unknown release of the Linux Kernel. Perhaps they might be helpful. http://kernelnewbies.org/documents/kdoc/kernel-api/linuxkernelapi.html http://www.llnl.gov/computing/tutorials/pthreads/ I only use Windows (obviously), so your library is good to go for me. But it would of been nice for Linux/FreeBSD users to have it too, so everyone can put this library in their INCLUDE directory, and use it when they need. Regards, Vincent ---------------------------------------------- ___ __________ ___ /__/\ /__________\ |\ _\ \::\'\ //::::::::::\\ |'|::| \::\'\ //:::_::::_:::\\ |'|::| \::\'\ //::/ |::| \::\\ |'|::| \::\'\ //::/ |::| \::\\|'|::| \::\'\__//::/ |::| \::\|'|::| \::\','/::/ |::| \::\\|::| \::\_/::/ |::| \::\|::| \::,::/ |::| \:::::| \___/ |__| \____| .``. ',,'
27. Re: Multitasking Preview Release
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Sep 24, 2005
- 610 views
- Last edited Sep 25, 2005
On Thu, 22 Sep 2005 18:39:02 -0700, Robert Craig <guest at RapidEuphoria.com> wrote: >You either need some kind of non-blocking I/O, On May 31, 2005 you wrote: I could easily add support for non-blocking IO* Any progress? With pipes? Regards, Pete PS * or similar words. My browser is crashing alot thesedays.
28. Re: Multitasking Preview Release
- Posted by Robert Craig <rds at RapidEuphoria.com> Sep 24, 2005
- 550 views
- Last edited Sep 25, 2005
Pete Lomax wrote: > > On Thu, 22 Sep 2005 18:39:02 -0700, Robert Craig > <guest at RapidEuphoria.com> wrote: > > >You either need some kind of non-blocking I/O, > On May 31, 2005 you wrote: > I could easily add support for non-blocking IO* > > Any progress? With pipes? I know that non-blocking I/O calls can be made on Windows and Linux, but I haven't tried to wrap anything, or otherwise put it into Euphoria. We'll see how things go. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
29. Re: Multitasking Preview Release
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Sep 25, 2005
- 534 views
Juergen Luethje wrote: > > > Thanks Daniel, TDLL is interesting. > However, I don't see how it can help to solve the problem. > In a reply to Vincent you wrote: > > "the whole tdll.e library is a replacement for dll.e" > > My Eu code does not use 'dll.e'. The code is translated and compiled > to a DLL itself. Of course I have no influence on the way how > Total Commander calls the code in my Eu DLL. > Am I overlooking something? > I think you need to yield control back to windows temporarily so that the main app can respond to messages. Have you tried perhaps sleep(0)? Matt Lewis
30. Re: Multitasking Preview Release
- Posted by Al Getz <Xaxo at aol.com> Sep 25, 2005
- 546 views
Matt Lewis wrote: > > Juergen Luethje wrote: > > > > > > Thanks Daniel, TDLL is interesting. > > However, I don't see how it can help to solve the problem. > > In a reply to Vincent you wrote: > > > > "the whole tdll.e library is a replacement for dll.e" > > > > My Eu code does not use 'dll.e'. The code is translated and compiled > > to a DLL itself. Of course I have no influence on the way how > > Total Commander calls the code in my Eu DLL. > > Am I overlooking something? > > > > I think you need to yield control back to windows temporarily so that the > main app can respond to messages. Have you tried perhaps sleep(0)? > > Matt Lewis > Hi Matt, Am i wrong, or does "sleep(0)" do absolutely nothing? In WinAPI, sleep(0) yields control to other processes, but in Euphoria it looks like it does nothing. Thus, he'll have to use the Win API call not Euphoria's sleep() right? Take care, Al Take care, Al And, good luck with your Euphoria programming! My bumper sticker: "I brake for LED's"
31. Re: Multitasking Preview Release
- Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 25, 2005
- 565 views
codepilot Gmail Account wrote: > On 9/23/05, Juergen Luethje wrote: >> >> codepilot Gmail Account wrote: >> >>> On 9/22/05, Juergen Luethje wrote: >> >> <snip> >> >>>> I wrote a plugin (a Windows DLL) for Total Commander. Sometimes, when >>>> the DLL reads/writes huge files, obviously Total Commander is not able >>>> to update the optical appearance of its main window, until the DLL has >>>> finished its work. <snip> > What part of you eucode is slow? Could you give me a general outline > of how the program works? The DLL reads text files depending on the situation line by line, or in chunks of 32 KB. And it copies text files, also using chunks of 32 KB. I wouldn't say that the EuCode is slow, but when the concerning files are big, especially on old computers it takes some time. Total Commander displays the GUI for the plugin, e.g. it asks: Do you want to copy the file 'foo.bar'? [Yes] [No] When the user clicks [Yes], my plugin does the work, and Total Commander shows some delay in updating its window. In the meantime I realized, that the same thing happens in situations where Total Commander only calls its own internal routines. So now it looks as if this hasn't got to do anything with my plugin. Thanks for considering the problem! Regards, Juergen -- Have you read a good program lately?
32. Re: Multitasking Preview Release
- Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 25, 2005
- 552 views
Matt Lewis wrote: > Juergen Luethje wrote: > >> Thanks Daniel, TDLL is interesting. >> However, I don't see how it can help to solve the problem. >> In a reply to Vincent you wrote: >> >> "the whole tdll.e library is a replacement for dll.e" >> >> My Eu code does not use 'dll.e'. The code is translated and compiled >> to a DLL itself. Of course I have no influence on the way how >> Total Commander calls the code in my Eu DLL. >> Am I overlooking something? > > I think you need to yield control back to windows temporarily so that the > main app can respond to messages. Have you tried perhaps sleep(0)? I had tried it previously, without success. Now, encouraged by your post, I did so again. I tried writing sleep(0) or sleep(1) at several different places in the source code -- no effect. Then I realized, that the same thing happens in situations where Total Commander only calls its own internal routines. So now it looks as if this hasn't got to do anything with my plugin. Thanks for considering the problem! Regards, Juergen -- Have you read a good program lately?
33. Re: Multitasking Preview Release
- Posted by Michael Nelson <mikestar13 at sbcglobal.net> Sep 25, 2005
- 560 views
I really like the new task API. Robert can do things with it that just simply be done in a library by building it into the interpreter. But the ideal of zero cost for programs that don't use it will not be realized in all cases. A case in point is my own Method Euphoria. I maitain a great deal of state information, inlcuding a call stack which tracks the "this" pointer, the currently running method, and various other things needed to enforce access rights--ME can only enforce protected or private access to a method because it tracks what method is callng it. If I make a task-safe version, I will need to maintain this data on a per task basis. So the state variables that are now integers become sequences, and those that are sequences become nested one level deeper. Every ME operation which acesses this state information will have an extra level of subscipting for each access (may be reduced somewhat but not eliminated by the creative use of temporaries). In addition, each operation will require a call to task_self. This will cause ME programs to run slower, even if they never use tasking. This issue will affect any library which maintains state information per program that would need to shift to maintaining state information per task. -- Mike Nelson
34. Re: Multitasking Preview Release
- Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 25, 2005
- 551 views
Michael Nelson wrote: > I really like the new task API. Robert can do things with it that just > simply be done in a library by building it into the interpreter. But the > ideal of zero cost for programs that don't use it will not be realized > in all cases. > > A case in point is my own Method Euphoria. [explanation snipped] > This will cause ME programs to run slower, even if they never use > tasking. > > This issue will affect any library which maintains state information per > program that would need to shift to maintaining state information per task. Maybe Rob could introduce a concerning "with" statement: with/without multitasking Just an idea. Regards, Juergen
35. Re: Multitasking Preview Release
- Posted by Robert Craig <rds at RapidEuphoria.com> Sep 25, 2005
- 563 views
Michael Nelson wrote: > I really like the new task API. Robert can do things with it that just > simply be done in a library by building it into the interpreter. But the > ideal of zero cost for programs that don't use it will not be realized > in all cases. > > A case in point is my own Method Euphoria. I maitain a great deal of > state information, inlcuding a call stack which tracks the "this" > pointer, the currently running method, and various other things needed > to enforce access rights--ME can only enforce protected or private > access to a method because it tracks what method is callng it. > > If I make a task-safe version, I will need to maintain this data on a > per task basis. So the state variables that are now integers become > sequences, and those that are sequences become nested one level deeper. > Every ME operation which acesses this state information will have an > extra level of subscipting for each access (may be reduced somewhat but > not eliminated by the creative use of temporaries). That's one way to do it. I haven't looked into the details of ME, but couldn't you do a full context switch of all of your ME data after each task_yield(), and also at the start of a new task, such that you copy (this may be just a pointer copy internally) all the ME data for the new current task into the simple variables that you use today? e.g. me_data1 = all_tasks_me_data1[task_self()] me_data2 = all_tasks_me_data2[task_self()] ... You could create an ME context-switch routine for this, and maybe create a wrapped version of task_yield() to add this extra operation. It would be extra overhead at each context switch, but if the user did not use multitasking, he wouldn't need it, and he would have little or no overhead. You could also retain the structure of all the ME internal variables you are using now. > In addition, each > operation will require a call to task_self. task_self() is a built-in function. Its cost is no higher than adding two integers. > This will cause ME programs > to run slower, even if they never use tasking. > > This issue will affect any library which maintains state information per > program that would need to shift to maintaining state information per task. I think most libraries could use a similar context-switching approach, but, yes, some library writers will now have to consider what to do if their users want to call the library from multiple tasks. In some cases the multiple tasks will act in concert, as one logical "user" of the library, with one set of global state information. In other cases, the library writer may want to maintain separate state information for each task. At least, with *cooperative* multitasking, it's easy to avoid the scary situation where two or more tasks might be executing inside the same library at the same time. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
36. Re: Multitasking Preview Release
- Posted by Al Getz <Xaxo at aol.com> Sep 25, 2005
- 586 views
Juergen Luethje wrote: > > Matt Lewis wrote: > > > Juergen Luethje wrote: > > > >> Thanks Daniel, TDLL is interesting. > >> However, I don't see how it can help to solve the problem. > >> In a reply to Vincent you wrote: > >> > >> "the whole tdll.e library is a replacement for dll.e" > >> > >> My Eu code does not use 'dll.e'. The code is translated and compiled > >> to a DLL itself. Of course I have no influence on the way how > >> Total Commander calls the code in my Eu DLL. > >> Am I overlooking something? > > > > I think you need to yield control back to windows temporarily so that the > > main app can respond to messages. Have you tried perhaps sleep(0)? > > I had tried it previously, without success. Now, encouraged by your > post, I did so again. I tried writing sleep(0) or sleep(1) at several > different places in the source code -- no effect. > > Then I realized, that the same thing happens in situations where Total > Commander only calls its own internal routines. So now it looks as if > this hasn't got to do anything with my plugin. > > Thanks for considering the problem! > > Regards, > Juergen > > -- > Have you read a good program lately? > > Hi Juergen, How about writing your own "Total Commander" in Euphoria? That way you'd truely have *TOTAL* control over how it works and you can modify it any way you choose. Perhaps a short description of T.C. the way it is now? Take care, Al And, good luck with your Euphoria programming! My bumper sticker: "I brake for LED's"
37. Re: Multitasking Preview Release
- Posted by Michael Nelson <mikestar13 at sbcglobal.net> Sep 26, 2005
- 608 views
Rob Craig wrote: >>I haven't looked into the details of ME, >>but couldn't you do a full context switch of all of your ME data >>after each task_yield(), and also at the start of a new task, >>such that you copy (this may be just a pointer copy internally) >>all the ME data for the new current task >>into the simple variables that you use today? e.g. >>me_data1 = all_tasks_me_data1[task_self()] >>me_data2 = all_tasks_me_data2[task_self()] ... >>You could create an ME context-switch routine for this, >>and maybe create a wrapped version of task_yield() >>to add this extra operation. >>It would be extra overhead at each context switch, >>but if the user did not use multitasking, he wouldn't need it, >>and he would have little or no overhead. >>You could also retain the structure of all the >>ME internal variables you are using now. Yes, of course that's it. That does reduce the cost to programs that don't use tasks to zero. All I would need is to redefine task_yield and do my context switching there. I could even make task_yield a no-op in contexts where task switching is inappropriate, for example in the middle of a class definition. This will add some overhead to task_yield, but fairly small. (I might also redefine task_create to reserve space for context switches to reduce the added overhead to task_yield.)
38. Re: Multitasking Preview Release
- Posted by "Juergen Luethje" <j.lue at gmx.de> Sep 26, 2005
- 604 views
Al Getz wrote: <snip> > How about writing your own "Total Commander" in Euphoria? > That way you'd truely have *TOTAL* control over how it works > and you can modify it any way you choose. > > Perhaps a short description of T.C. the way it is now? You want a short description of Total Commander? Look here please: http://www.ghisler.com/ Regards, Juergen