1. Multitasking Preview Release
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
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
-
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
-
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
-
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
-
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
-
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
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
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
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
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
-
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
-
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
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
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
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
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
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
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
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
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
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
-
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
-
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
-
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
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
-
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
-
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
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
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
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
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
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
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
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
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
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
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
