Re: same problem , version 2
- Posted by useless Aug 30, 2009
- 809 views
Would a dll placed between the Eu keyword and the win32 call work? If existing Eu "system()" is redirected in the source code to point to a Eu dll instead of kernal386 (or whichever), could that dll pass the call to windoze and then immeadiately return to the Eu code? Or, perhaps this is a good reason to make a threaded call to these blocking functions? I see no way atm to write Eu code that can issue a system() or dir() call and then go do stuff while waiting on the OS to reply.
If by redirecting, you mean somehow making a dll replace the keyword in the interpreter? That would be really tricky to do without modifying the source code of the interpreter itself (but, really easy to do if someone is willing to modify the source code of the interpreter itself).
Using an Eu dll means that there are two Eu engines running - the main interpreter and the Eu engine running inside of the dll. So it would be much safer to use threads inside the Eu dll to prevent the blocking.
I don't think there would be any other benefit to using a dll, though, and with the right W32API calls multithreading is not needed to turn system() into a nonblocking call. It's just a little bit more work to do on Windows then on Linux. (Actually, it could be done in 100% Eu once the W32API calls were wrapped.)
The last option you mentioned is prolly preferable, making it more likely that the non-blocking-system() can smell like an Eu task, so we can use existing task operators to know if it's done, maybe. I just figured if it was possible just by wrapping the right calls, it would have been done already.
useless
