1. Win32LIB dreams
What i would really like to see for Win32Lib is the ability to write call
backs for background processing... if that is at all possible, i find that
the timer is a little too slow even at 1 ms, and using a call back routine
for a thread is not at all safe, and you can't suspend or resume it without
crashing. So where i stand, background processing is the last place to go.
Ps, if it is already possible please inform me on how it is done!
Ian
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
2. Re: Win32LIB dreams
No Solution wrote:
> What i would really like to see for Win32Lib is
> the ability to write call backs for background
> processing...
This would require that Euphoria support threads, which is currently does
not.
-- David Cuny
3. Re: Win32LIB dreams
Hi Ian,
>What i would really like to see for Win32Lib is the ability to write call
>backs for background processing... if that is at all possible, i find that
>the timer is a little too slow even at 1 ms, and using a call back routine
>for a thread is not at all safe, and you can't suspend or resume it without
>crashing. So where i stand, background processing is the last place to go.
>Ps, if it is already possible please inform me on how it is done!
Can you exapnd on this a little.
Are you talking about Windows calling a user-defined Euphoria routine? If
so, have you read up about Euphoria's call_back function?
--------------------------
call_back
Platform: WIN32, Linux
Syntax: include dll.e
a = call_back(i)
Description: Get a machine address for the Euphoria routine with routine id
i. This address can be used by Windows, or an external C routine in a
Windows .dll, or Linux shared library (.so), as a 32-bit "call-back" address
for calling your Euphoria routine.
Comments: You can set up as many call-back functions as you like, but they
must all be Euphoria functions (or types) with 0 to 8 arguments.
When your routine is called, the argument values will all be 32-bit unsigned
(positive) values. You should declare each parameter of your routine as
atom, unless you want to impose tighter checking. Your routine must return a
32-bit integer value.
Example Program: demo\win32\window.exw, demo\linux\qsort.exu
See Also: routine_id, platform.doc
--------------------------
cheers,
Derek Parnell
4. Re: Win32LIB dreams
On 20 Oct 2000, at 11:14, Derek Parnell wrote:
> Hi Ian,
>
>
> >What i would really like to see for Win32Lib is the ability to write call
> >backs for background processing... if that is at all possible, i find that
> >the timer is a little too slow even at 1 ms, and using a call back routine
> >for a thread is not at all safe, and you can't suspend or resume it without
> >crashing. So where i stand, background processing is the last place to go.
>
> >Ps, if it is already possible please inform me on how it is done!
>
> Can you exapnd on this a little.
>
> Are you talking about Windows calling a user-defined Euphoria routine? If
> so, have you read up about Euphoria's call_back function?
>
> --------------------------
> call_back
> Platform: WIN32, Linux
> Syntax: include dll.e
> a = call_back(i)
> Description: Get a machine address for the Euphoria routine with routine id
> i. This address can be used by Windows, or an external C routine in a
> Windows .dll, or Linux shared library (.so), as a 32-bit "call-back" address
> for calling your Euphoria routine.
So..... what happens if you have two Eu programs,
prog1.ew
procedure a
gets(1,b_callback)
--- code using b_callback
end procedure
a_callback = routine_id(procedure a)
puts(1,a_callback)
-- end program
prog2.ew
procedure b
gets(1,a_callback)
--- code using a_callback
end procedure
b_callback = routine_id(procedure b)
puts(1,b_callback)
-- end program
I can think of several ways to transfer all the routine_ids between any number
of
running programs, i used gets() cause it gets(the point across). This
two-program
approach naturally holds two running interpreters in memory, but that's why it
is
multitasking. You cannot expect any global vars will be shared, but transfering
them or
redeclaring constants in each program should be easy enough. If windoze pages
the
applications out to the disk swap file, something may crash, but if that is the
case,
lock the memory the procedures are using.
Kat,
wishing she had time to try this herself.
