OpenEuphoria

Re: Multitasking Preview Release

• Posted by Vincent <darkvincentdude at yahoo.com> Sep 22, 2005
• 574 views

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