In response to Stephen001
We were under the impression that, internally, dantom.db's mysql interface (that is, not the relatively-recent sqlite support) either relied on call() or something similar, since the issues people have listed in this thread are almost identical to the issues we've been having with MySQL.
Nah, calls onto _dm_*() methods (as seen in Dantom.DB's core.dm itself). They will in turn be calling libmysql presumably via dl() and such, similar to how call() needs to in order to call the DLL, but it can convert data-types internally as needed and track the connection natively unlike call().

The only common aspect really is that both happen to call onto a DLL dynamically to do work, but this isn't exactly an abnormal or unusual C++ scenario, so I doubt there's anything special and common between the two.

They are very much best explored separately, particularly as both are very dependent on what you're actually doing and represent quite different things.

The Dantom.DB aspect has very SQL specific external factors that affect performance, like how your SQL queries are, round trip to MySQL server, I/O on MySQL server.

Where-as call() depends very much on whatever the heck you actually put into your DLL that you are calling, compilation options within that build process yadda yadda.
I suspect both would benefit from being able to sleep the proc and wait for a response, but I think first I need to handle the issue of being able to resume sleeping procs in the dead space within a tick.
I'd agree.

DLL implementations do have have a pretty good workaround here though, depending on what they are doing. Non-blocking I/O models, threading models etc. Some obviously won't quite suit without a separate polling call() to pick up results, but some would fit that perfectly and mitigate the potential tick hogging behaviour we see today. It's a trade-off the DLL implementation can consider and make though.
Page: 1 2