On Dec 10, 2007, at 7:22 PM, Dimitri Glazkov wrote:
Guys, I think the point was that it's not unreasonable to have synchronous API. The argument about slow/busy devices is valid, but I still think the developer should have the choice of either going with a simple query/receive calls in their code as opposed to braving complexity of asynchronous API. I fully agree with this point and do believe that if it's a low-hanging fruit, it should be included into the implementation.
I'm not sure it is doing the developer any favors to make it easy to write code that will fail in unpredictable ways. Note that 5 seconds is not really a perfectly acceptable time to stall the UI, it is the lower edge of totally unacceptabe, and yet it's not unlikely that apps will sometimes blow this limit and randomly fail instead of getting slower when the user's system is slow or under load.
Furthermore, I am biased, but think that threading model in Gears is a pretty good approach to this problem. Instead of building the asynchronous (and complex) database API, offer a simple worker pool API and a simple synchronous database API.
I do think that message-passing threads + sync API is a reasonable and good thing. But I still think sync I/O on the main thread is not a good idea. I haven't heard anything to really convince me otherwise.
Regards, Maciej
