None of the above. Pool your TCP connections on top of a few threads, and independently pool your few database connections on top of another set of threads. Make the actual queries asynchronous by queuing them through the tread pool. The solution's rather complex, though, and 1000 connections ain't that much, so you may be able to get away with a single thread for the TCP stack and a single thread for the SQL stack.

@sykac said in Turning off power to a running QSerialPort: One problem starts probably in the hardware. The COM port of the device disconnects from the PC (I don't why, it could be some driver/firmware issue) Reading you topic title, could it be that the USB connection between PC and FTDI is interrupted? And that's what I said, this may lead to endless loops in the device driver. This kind of problems can hardly be solved in the user space.

@jsulm It's alright. I ended up going completely asynchronous by using a chained callback structure. Thanks anyways for the help!

After a detailed research of various asynchronous techniques such as Promises, Futures, Tasks and Reactive Extensions we came with a new paradigm that solved all our asynchronous problems very elegantly: The Streams Paradigm It's inspired by the reactive approach, though superior in many aspects such as abstraction, abortion, resumables etc. It's a completely rethought way of writing declarative code, making complex asynchronous operations and transactions (and probably even concurrency) a piece of cake! Nearly everything can be represented, thus abstracted away by a stream.. UI Elements Sockets Requests (HTTP etc.) Calculations the list goes on... This way streams become a consistent protocol of asynchronous and concurrent communication between various application components ranging from the UI frontend to the networked backend. We published the first beta release of a QML implementation with a working example aboard, be sure to check it out! https://qbeon.github.io/QuickStreams/

Good news! My use case is actually well covered by simply using a regular .import "thing.js" as Thing. I don't need the specific namespace-less behavior of Qt.include; I just happened to miss .import when reading the doc, thus failing to understand that Qt.include is only a second import mechanism to be used instead of .import under very specific (documented) circumstances. → Doc might still deserve clarification of the async behavior, but my initial problem is gone with using .import. I updated the QTBUG

@jramm, signals are methods. You can declare a signal as Q_INVOKABLE and call it from JS.

@JKSH Oh, did not catch that difference. Thank you.

Hi chocis, Yes Yes, otherwise container will contain a bunch of undefined objects. The objects are destroyed immediately when destroy() is called and their memory is also freed immediately (the javascript garbage collector is not involved in this case). The objects are instantiated immediately when createObject() is called, but they are rendered the first time after returning from the onClicked javascript code block. Don't know. You need to measure. If your targeted hardware supports multiple threads: Create the objects outside the GUI thread. Either use incubateObject() in QML or do it in C++ with QThread. In addition: Create invisible objects when the CPU / GUI thread is idle and set them visible as soon as you need them. Don't know. You need to measure. Send signals from QML to other (C++) threads to terminate them. Don't know. Like you already stated, if the component you want to instantiate isn't in a separate qml file then Loader can't be used. Try incubateObject(). Cheers! Wieland