On Wed, Nov 9, 2011 at 6:05 PM, Jeremy Lainé <jeremy.la...@m4x.org> wrote: > This talk about QtConcurrent has me wondering: do we need an asynchronous API > at all?
I really dislike synchronous APIs, even more so when they're the only option. Reason being that most 'normal' people won't make the effort to get it right, even when that effort is just creating a slot. I've seen this repeatedly in code like QtContacts, as well as complaining about things like QNAM not enabling them to make those mistakes. Now, while I'm a consultant, and according to the usual jokes, I get paid to fix other people's mistakes, I'd rather not create more capabilities for people to make them. ;) DNS requests can also potentially block for rather a long time, so having this be asynchronous is, I think, just generally a good thing. Deficiencies of platform API aside, we could always just write a DNS resolver by hand instead of using a threadpool, if there was really a need for it - it's really not that hard. I don't think any of the problems that have been brought up are too unsolvable really, and I think you're on a good path with this work. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
