Re: Multitasking Preview Release
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
>
>
>
>
|
Not Categorized, Please Help
|
|
