Как реализуется ? Знаю что есть poll, который может проверить когда можно отправлять, знаю что send на "неблокируемый" сокет вернет сколько байт отправлено... Т.е. мне надо хранить кучу PTR'ов и организовывать логику отправки "по кусочкам"...... Вопрос - как это сделать по-людски ? Сделать в смысле следующее :
1. Есть дескриптор, в который отправляем файлО. (гигов эдак десять).
2. Есть второй дескриптор, который должен в интерактивном режиме реагировать на команды. 
Чего делать ?

Доп. условия :
Поток отправки не создавать. Ну не нужен мне лишний процесс   





Это сообщение отредактировал(а) GrayCardinal - 2.10.2006, 13:44

Может select'ом следить за обоими дескрипторами?

а чего так, вроде при COW создание процесса не так расточительно
а вообще может так с select-ом

еще можно таймер поставить, чтобы одна операция другую по времени не вытеснила

Это сообщение отредактировал(а) MAKCim - 2.10.2006, 15:40

без лишнего процесса мона юзать sleep(MAX_DWORD) который совсем не жрет процессор. чем не нравится создать новый тред или вкинуть select в while(true)

варианты:

1. select()/poll() (это одно и тоже)
2. спать по милисекундам
3. треды
4. ловить SIGIO выставив сокет в O_ASYNC (никогда таким извращением не занимался)
5. форкаться, делать в дите всю работу и умирать

при всем богатстве выбора, альтернативы вариантам 1 и 3 нет. 5 -- по обстоятельствам.

MAKCim, 
Как определять размер "очередной порции", чтоб небыло блокировки ?

Добавлено @ 08:55 
dmiceman, 
Меня именно интересует вариант реализации при помощи select/poll. Если я после select что-то оправлю и канал окажется уже, прога у меня заблокируется до окончания передачи   

а если вынести отправку в отдельный тред, то все будет в порядке

smalcom, 
Предлагаешь создавать тред, который 99.99% своего времени будет простаивать (ожидая завершения отправки) ?   

пусть себе стоит он шо мешает. а во вторых почему стоит?

smalcom, 
Ну не лежит же   

как тока упадет бум его пороть

ты не можешь определить размер рабочей порции. то есть тебе нужно иметь буфер отправки и буфер приема. писать и читать в дескрипторы следует в неблокирующем режиме (O_NONBLOCK). read() и write() для того и возвращают размер принятых/отправленных байт. и на оба дескриптора сажается select() в цикле.

потом, если в командный дескриптор пришла полная команда -- обрабатывай. как ты будешь определять полная ли это команда сидит в буфере -- зависит от задачи. большинство демонов с текстовым интерфейсом (pop3, ftp, smtp) разделяют команды переводами строк.

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

Поставь O_NONBLOCK на сокет
Насколько я знаю для каналов в этом случае возможна частичная запись если размер передаваемых данных больше текущей вместимости буфера. По идее с сокетами тоже должно работать, но не уверен
Еще по-моему в настройках сокета с помощью setsockopt можно указать нижнию границу объема передаваемых данных, и если количество данных меньше чем это граничное значение, write на сокете не блокируется

Мне кажется все таки использование здесь потоков/процессов логичнее, имхо, конечно

Это сообщение отредактировал(а) MAKCim - 3.10.2006, 17:40

Угу. Всем спасибо... Остановился на варианте с вилкой. Написал Dtransmit которая файло перекидывает и забыл  про траблу  И не волнует что она в другом процессе выполняется  

Асинхронный ввод-вывод: aio_xxx