So much head desk in here, I don't even...
Uhrwerk, thanks for your patience, I would have lost it already here...

Quote:
Well if you do network stuff you HAVE to wait because your internet is not as fast as your CPU.

In which case the DLL function wouldn't be blocking anymore, but asynchronous. You can't just decide to wait one frame and then be sure that the data arrived, networks are unpredictable. When you have an asynchronous function, you wait for a notification, normally using a callback. In any case though, the returned value from the function will not EVER change at all. It's a local variable, the callee has no way to return multiple values to the callee, or update the returned values. This isn't functional programming here.

In any case though, if Neos problem is fixed with a wait_for, than his stuff is seriously broken. wait_for() doesn't fix the problem, it just masks it. It's hard to tell what is going on, because we don't see what sql_select() does, but since it's a DLL method we can, with 100% certainty conclude that in no way does it call wait(). Also, if it did, it wouldn't return anything since wait() doesn't allow to return values to the caller.

So, to recap: Neos DLL function IS blocking. It can't call into wait(), so upon its return, it is done. If Neo kicks of an asynchronous task in the DLL function, than wait_for() won't help him wait for the results, since, again, the DLL function is done!

Both of you, please read up on how normal code execution flow works. Stuff doesn't just magically happen concurrently so that you have to synchronize it, and even if it did, wait_for() is the tank-through-the-door-instead-of-using-the-key approach of synchronization.


Shitlord by trade and passion. Graphics programmer at Laminar Research.
I write blog posts at feresignum.com