Здравствуйте, 00011011, Вы писали:

0>Здравствуйте, Zhendos, Вы писали:

Z>>Вот статья от разработчиков Qt по этому поводу: https://www.qt.io/blog/2010/06/17/youre-doing-it-wrong .

0>Низкоуровневые API для многопоточности предполагают наличие некоторой функции создания потока, которой передается в качестве аргумента указатель на гдавную функцию потока и ее аргументы (CreateThread, pthread_create и т.д). Нечто похожее есть в QThread: static QThread *create(Function &&f, Args &&... args). Предлагаете использовать ее? Есть какие-то примеры как надо делать?

Ну все зависит от ваших задач. Я предлагаю только не использовать наследование от QThread.
Пример как это делать самый первый в документации к QThread. Ну и здесь уже в посте
есть другой пример, но с тем же принципом — наследование от QObject.

0>Честно говоря, для меня оказалось удивительно что объекты Qt каким-то образом принадлежат потокам, а не просто существуют в памяти. В чем физический смысл этой принадлежности? Мне кажется, это какое-то усложненение, наверное обусловленное архитектурой Qt. Хотя я об этом где-то прочитал, и по этой причине объявил сокет изначально как локальную переменную в функции потока, а затем оказалось что он нужен и в слоте — поэтому по быстрому переделал в указатель.

Ну теперь вы поняли что это не усложнение, а реально нужная вещь? На примере собственной ошибки.

Пользователь обычно не делает слоты рассчитанными на вызов из разных потоков
одновременно. Поэтому `connect` заботиться об этом, используя информацию о
том что "receiver" и "sender" располагаются в разных потоках, `connect` заботиться
о том, чтобы несмотря на то что сигнал был вызван в потоке в котором живет
"sender", слот будет вызван в потоке "receiver". И никакой "data-race" не будет.
Так же это помогает в отладочной сборке валидировать с помощью assert и "QThread::currentThread"
правильное использование потоков.

И в эту прекрасную картину правильного использования многопоточности не укладывается только
одна вещь — QThread. Вернее его использования с наследованием, интуитивно кажется что
сам QThread должен принадлежать самому себе. Но это не так, по умолчанию
он принадлежит потому в котором создан.

Здравствуйте, 00011011, Вы писали:

0>Здравствуйте, Zhendos, Вы писали:

Z>>Вот статья от разработчиков Qt по этому поводу: https://www.qt.io/blog/2010/06/17/youre-doing-it-wrong .

0>Низкоуровневые API для многопоточности предполагают наличие некоторой функции создания потока, которой передается в качестве аргумента указатель на гдавную функцию потока и ее аргументы (CreateThread, pthread_create и т.д). Нечто похожее есть в QThread: static QThread *create(Function &&f, Args &&... args). Предлагаете использовать ее? Есть какие-то примеры как надо делать?

Ну все зависит от ваших задач. Я предлагаю только не использовать наследование от QThread.
Пример как это делать самый первый в документации к QThread. Ну и здесь уже в посте
есть другой пример, но с тем же принципом — наследование от QObject.

0>Честно говоря, для меня оказалось удивительно что объекты Qt каким-то образом принадлежат потокам, а не просто существуют в памяти. В чем физический смысл этой принадлежности? Мне кажется, это какое-то усложненение, наверное обусловленное архитектурой Qt. Хотя я об этом где-то прочитал, и по этой причине объявил сокет изначально как локальную переменную в функции потока, а затем оказалось что он нужен и в слоте — поэтому по быстрому переделал в указатель.

Ну теперь вы поняли что это не усложнение, а реально нужная вещь? На примере собственной ошибки.

Пользователь обычно не делает слоты рассчитанными на вызов из разных потоков
одновременно. Поэтому `connect` заботиться об этом, используя информацию о
том что "receiver" и "sender" располагаются в разных потоках, `connect` заботиться
о том, чтобы несмотря на то что сигнал был вызван в потоке в котором живет
"sender", слот будет вызван в потоке "receiver". И никакой "data-race" не будет.
Так же это помогает в отладочной сборке валидировать с помощью assert и "QThread::currentThread"
правильное использование потоков.

И в эту прекрасную картину правильного использования многопоточности не укладывается только
одна вещь — QThread. Вернее его использования с наследованием, интуитивно кажется что
сам QThread должен принадлежать самому себе. Но это не так, по умолчанию
он принадлежит потоку в котором создан.