одновременная запись и чтение сокета (+)

не проверял, но не вижу причин почему бы это было невозможно. Буферы на приём и передачу разные и независимые.

>Буферы на приём и передачу разные и независимые.

буфера то разные, но вот дуплекс не везде полный.

> но вот дуплекс не везде полный

Could you elaborate on this?

>> но вот дуплекс не везде полный

> Could you elaborate on this?

Например, COM-port с PPP не является дуплексным каналом :) Полагаю, что *DSL тоже.

> Например, COM-port с PPP не является дуплексным каналом :) Полагаю, что *DSL тоже.

почему RS232 не является дуплексным каналом? по крайней мере на уровне интерфейса к железу и разводки это вполне даже себе дуплексный канал. отдельные линии приёма/передачи данных есть, раздельные буфера приёма/передачи то-же.

// wbr

> почему RS232 не является дуплексным каналом?

Самая распространенная распайка кабеля не является дуплексной, AFAIK :)

Да, можно. Сложности так, не особо... Например, close() не будет прерывать заблокировавшуюся операцию. А на других системах может и будет - такой мутноватый момент.

> Самая распространенная распайка кабеля не является дуплексной, AFAIK :)

почему же? наоборот, на RS232 везде есть разнесённые RX/TX и земля. управляющие сигналы по желанию.

// wbr

Вообще-то да, возможно, наверное. А стандартные драйверы это поддерживают?

> Вообще-то да, возможно, наверное. А стандартные драйверы это поддерживают?

по идее да. по крайней мере приём и передача данных тактируются по прерыванию, буфера туда-сюда разные, регистры естественно то же etc.

// wbr

ну я так делал, все отлично работает. не вижу причин почему это не должно работать.

>> но вот дуплекс не везде полный

>Could you elaborate on this?

тот же самый ethernet switch... порт свича может быть и не в полном дуплексе, не смотря на то, что есть и RX и TX.

> порт свича может быть и не в полном дуплексе

при чём тут это? это уже проблема сетевухи и её phy. Не путайте тёплое с мягким. Мы говорим о transport level в моделе OSI

>> порт свича может быть и не в полном дуплексе

> при чём тут это? это уже проблема сетевухи и её phy. Не путайте тёплое с мягким. Мы говорим о transport level в моделе OSI

А зачем тебе одновременные запись/чтение, не для того, чтобы данные физически одновременно посылались и принимались?

>А зачем тебе одновременные запись/чтение, не для того, чтобы данные физически одновременно посылались и принимались?

я думаю вопрос был поднят для того чтобы узнать нужно ли лочить доступ к сокету когда работают несколько потоков)

> буфера то разные, но вот дуплекс не везде полный.

а причем вообще здесь дуплекс канала?

работа сокета (читай реализация сокета в ядре) вообще не зависит от выбранного канала.

единственное, что может быть: одновременная запись и чтение сокета может и вообще ни разу не произойти при полудуплексе. но это не значит, что ядро не поддерживает такую возможность.

Как же я в своё время намучился из-за того, что блокирующий read() нельзя прервать прервать этим close(). Под Линуксом ещё ничего: select, дополнительный pipe для передачи сообщения о том, что больше не хочу читать. А под виндой пришлось программировать их NamedPipes...

Андрей