On Apr 9, 2:12 pm, Artur <[email protected]> wrote: > I do think we're going to run into performance issues with more demanding > applications,
I think that if you want to do real-time video decoding, that should not happen on the main (node) thread anyway. > like real-time video decoding for example. At that point -- > and if necessary -- perhaps we could join the event loop via nextTick()? Well, I think that that would actually busyloop the application - so unless you don't care about battery life (and burning genitalia) I would not recommend it. > (Qt only has two entry points for its event loop API -- > QApplication.processEvents() which is non-blocking, and QApplication.exec() > which is blocking). I think you can also implement QAbstractEventDispatcher. There's a fundamental problem (at least on windows) that makes this problem rather difficult to work around nicely. GUI objects are bound to a thread, so if the main thread creates the windows and controls, the main window must also process gui events. However the "poll" function in libuv (GetQueuedCompletionStatus) cannot report gui events. It is also not possible to poll for gui events in another thread (at least not with documented APIs - I am sure there must be a way though). So the only solution would be to move GetQueuedCompletionStatus to another thread, and dispatch the events that it reports to the gui message pump that runs in the main thread. This would probably make node's i/o performance much worse. Libuv is also lacking appropriate APIs for installing this kind of hack. So I am unsure how to proceed here. - Bert -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
