А мне интересен результат анализа какой-нибудь BSD системы, лучше NetBSD. А то БСДшникам обидно. На мой взгляд, у них очень качественный код, возможно, из-за своей консервативности.
Если thread-safe, значит можно как хочешь, хоть с одним дескриптором, хоть с дестью.
А пример с буфером плохой. Причем тут ядро? С его точки зрения все нормуль и его поведение не меняется.
А в нашем случае меняется — BUG.
Я, в свое время, даже тест написал для отлова этого эффекта tty системы. Теперь ваша очередь для сокет. lkml.org/lkml/2012/12/18/368
Смысл в следующем:
Если один поток находится в системном вызове read, например, то второй, может войти в системный вызов close (все это для одного и того же последнего, открытого дескриптора файла). По хорошему, второй должен пометить дескриптор как закрытый, для предотвращения дальнейших попыток чтения/записи, дождаться завершения, а лучше прервать, начатый другим потоком read, и вернутся нормально в user space после read, но как обычно есть нюансы. Бывает, как было с tty, close отработал, а read все пытается читать в уже освобожденную память закрытого файла. В вашем случае, видимо, что-то помягче.
А вы про какую Windows говорите? В Windows 8.1, появился: «Per monitor-DPI aware». Про «DPI aware» в Windows
QTIPlot или QT это учитывают? Может в этом проблема? И на Windows < 8.1 все нормально.
Попробуйте отключить, «Per monitor-DPI aware», на Windows 8.1 это возможно.
А если в коде ошибка или сбой произошел и tty->buf.tail == NULL, вернемся к тому с чего начали.
Или после сбоя, ошибки всегда tty->buf.tail != tty->buf.head — зависнем под lock с запрещенными перерываниями.
Хотя я уже написал, что так было бы яснее и возможно лучше.
Тут проблема была в следующем:
Это код, изначально, так называемого flip буфера, пишем в один, читаем из другого, причем одновременно, потом меняем их местами, lock ставится только на момент смены буфера, на очень короткое время. Затем, количество буферов увеличилось, код изменился, но принцип остался.
что может устранить race condition
А нет больше никакого race condition. Мы просто не удаляем последний буфер, в который может идти запись, только стираем накопленные там данные.
А что непонятно?
1. Можно пытаться избегать доступа по указателю со значением NULL.
2. По возможности избегать указателей со значением NULL. Например, заранее выделять память или как в статье, освобождать ее не полностью.
Конечно, не всегда так получится, но если есть такая возможность, второй подход, по моему мнению, лучше.
Подскажите, пожалуйста, а в «Debian» «proftpd --version» не работает?
В чем смысл через «aptitude»? Неужели так можно получить разный результат?
Конструктор «КубиТрёх».
Конструктор «ТреКуб».
lkml.org/lkml/2012/12/18/368
Тоже потоки, тоже дескрипторы.
А пример с буфером плохой. Причем тут ядро? С его точки зрения все нормуль и его поведение не меняется.
А в нашем случае меняется — BUG.
И их поведение не должно зависеть от количества threads их вызывающих, значит BUG.
Thread-safe functions
Там чуть больше чем ничего.
lkml.org/lkml/2012/12/18/368
Смысл в следующем:
Если один поток находится в системном вызове read, например, то второй, может войти в системный вызов close (все это для одного и того же последнего, открытого дескриптора файла). По хорошему, второй должен пометить дескриптор как закрытый, для предотвращения дальнейших попыток чтения/записи, дождаться завершения, а лучше прервать, начатый другим потоком read, и вернутся нормально в user space после read, но как обычно есть нюансы. Бывает, как было с tty, close отработал, а read все пытается читать в уже освобожденную память закрытого файла. В вашем случае, видимо, что-то помягче.
Про «DPI aware» в Windows
QTIPlot или QT это учитывают? Может в этом проблема? И на Windows < 8.1 все нормально.
Попробуйте отключить, «Per monitor-DPI aware», на Windows 8.1 это возможно.
Или после сбоя, ошибки всегда tty->buf.tail != tty->buf.head — зависнем под lock с запрещенными перерываниями.
Хотя я уже написал, что так было бы яснее и возможно лучше.
WARN_ON(buf->head != buf->tail);
Указатель, на начало списка буферов, сразу инициализируется не нулевым значением и больше нигде не проверяется на значение NULL.
Это код, изначально, так называемого flip буфера, пишем в один, читаем из другого, причем одновременно, потом меняем их местами, lock ставится только на момент смены буфера, на очень короткое время. Затем, количество буферов увеличилось, код изменился, но принцип остался.
А нет больше никакого race condition. Мы просто не удаляем последний буфер, в который может идти запись, только стираем накопленные там данные.
1. Можно пытаться избегать доступа по указателю со значением NULL.
2. По возможности избегать указателей со значением NULL. Например, заранее выделять память или как в статье, освобождать ее не полностью.
Конечно, не всегда так получится, но если есть такая возможность, второй подход, по моему мнению, лучше.
А то, не очень ясно.