- 1
- 2
- 3
- 4
- 5
- 6
void sleep_in_qt_ms(unsigned millisec) {
QMutex foo;
foo.lock();
foo.try_lock(millisec);
foo.unlock();
}-
C++ / Говнокод #12827
+24
sleep в Qt - что, серьезно, чтоли?
особенно порадовало: Warning: Destroying a locked mutex may result in undefined behavior.
действительно, накой нам деструкторы?Запостил:
defecate-plusplus,
29 Марта 2013
Follow us!
> Warning: Destroying a locked mutex may result in undefined behavior.
Ну дык мутекс мог залочить один поток, а второй вызовет у него деструктор... Вот видимо такие случаи и имелись в виду.
только передать во второй поток этот мутекс по ссылке и указателю (надеюсь, что QMutex - noncopyable, верно?)
раз так, то это плохо вообще для чего угодно, даже для инта, дереференситься к удаленному объекту
Хм. Ну а нахрена, простите, сдался мутекс, если его не юзают как минимум 2 потока?
например, потоки работают по методам одного и того же объекта, и понятное дело, они оба имеют доступ к мьютексу - члену этого объекта - и тут оба потока обязаны умереть раньше, чем вызовется деструктор мьютекса
Да тут будет та же самая проблема, если какой-то из потоков надумает выпилить этот объект (да, естественно, так никто делать не будет, как собственно и разрушать мутекс не сняв с него локи).
> оба потока обязаны умереть раньше, чем вызовется деструктор мьютекса
Воот... Правильная мысль. Юзеры объекта должны перестать пользоваться мутексом до вызова его деструктора. А если они перестали им пользоваться - они мало того, что его анлокнули, так еще и должны воздержаться от последующих вызовов lock(). Следовательно проблема с undefined behavior надуманная, и возникает только в кривых случаях, которые сами по себе undefined behavior.
Вызвал lock() вручную - будь добр вызвать unlock() в том же треде тоже вручную.
P.S. Прога с непарными lock()/unlock() она ведь сама по себе уже бажная...
всё равно в будущем, если придется писать нормально, то придется писать с нуля, а не пользоваться qt-шным примером
постигла меня эта кара к концу недели, измазался уже по самое немогу
Чувствую, дойдёт дело до Boost.GUI.
> GUI
да нет, самый настоящий QUЇ
вот мне прямо сейчас сдался, например, а компилить буст для демки тестовой платформы мне пока что очень западло
> QThread::sleep()/usleep()/msleep()
превосходная идея с клонированием сотни одинаковых функций, вместо того, чтобы сделать нормальный класс, хранящий duration (QMilliseqonds, да) и передавать его один в одну функцию Qsleeq
впрочем, я не удивлен
struct Sleepy : private QThread {
static void sleep(int ms) {
QThread::sleep(ms);
}
};
У вас сарказм отвалился. Вы же это не серьезно, да?
много писанины. я пару софтин перевел на double для хранения таймаутов и прочего. 30 - 30 секунд, 0.5 - 500мс, 0.0001 - 100юс, и т.д.
protected sleep подразумевает, что нужно наследоваться, а наследование тут нафиг не нужно. Логично как в PHP
Что-то типа NetworkInMainThreadException в андроиде.
так бездаqно сделать интеqфейс, когда столько пqостоqа для полёта мысли:
class QMuteqs
QMuteqs::QReqursionMode
QMuteqs::loQ(), unloQ(), tryLoQ()
совсем новыми красками заиграло ведь
KOGDA WESENNIJ PERWYJ GROM,
KAK BY REZWQSQ I IGRAQ,
GROHO^ET W NEBE GOLUBOM.
kAKAQ BOLX,
aRGENTINA - qMAJKA PQTX - NOLX.
тред работает, создает мутекс для себя, лочит его и его же и ждёт заданное число времени
никакой другой тред не в курсе про этот мутекс