Народ!

Кто-нибудь знает, есть ли в природе способ соединить два сокета без помощи третьего (т.е. без listen и accept)?

То есть примерно что-то следующее:

---один поток:
...
bind(socket1, ....)
select(....
recv(socket1, ...)
...

---другой поток
connect(socket2, ...) //коннектимся по заранее известному адресу
send(socket2, ...)

Нет, не между потоками.
Про потоки - это я для примера попроще...

Естественно, я про передачу данных между разными хостами.


Нужно - "для экономии на спичках".

Пишу что-то типа спайдера для мобильного устройства.
Ресурсов - кот наплакал, предел для стека потока - 64 кб.
А когда с десяток потоков крутится в памяти, то загрузка процессора 100%.

Вот и пытаюсь экономить где можно.
Жалко, профайлера нету никакого...

AkhМысля: а можно закрыть базовый сокет, после получения соединения?Базовый, в смысле серверный? Который Listen?
Ну, в принципе можно, конечно, но через 150 мсек его опять создавать придется...

Gluk (Kazan)Проверять список сокетов select-ом из ОДНОГО потока
accept можно ловить тем-же select-омУ каждого потока порты, по которым сеть слушается - разные. :(
Да и толку от создания еще одного лишнего потока...
И так протолкнуться негде. :)

onstat-Делать через обработку сигнала SIGIO, если пишется под Unix.К сожалению, пишу под Win...

В общем, понятно, что под Win32 ловить нечего. :)

onstat-Select нужно крутить в одной нити для всех дескрипторов, а другим "говорить" что для них что то есть на обработку.

Для такой схемы мне нужен будет лишний поток,
и пачка аспирина, чтобы синхронизировать то, что без лишнего потока синхронизировать было не нужно...

Дело не в том, что мне мешает блокировка при ожидании входящего соединения в потоке.
Она-таки как раз помогает.
Ибо на один поток - один приходящий сокет.
Просто я хотел обойтись всего одним сокетом в потоке,
но видно не судьба.

А лишняя нить для всех дескрипторов - это:
1. синхронизировать передачу в эту нить нового дескриптора.
(дополнительный объект синхронизации для "лишней" нити)
2. как-то остановить свою нить, дожидаясь сообщения от "лишней".
(дополнительный объект синхронизации (event) для каждой из рабочих нитей).
3. синхронизировать все последующие манипуляции с дескриптором.

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

И куча лишнего геморроя с синхронизацией, и ожиданием передачи управления между потоками.

White OwlЗачем??? Ты уверен что тебе на микро-ресурсах действительно нужна параллельная обработка приходящих данных?
Не уверен.
Но пока проект сырой, и проще отлаживать каждый экземпляр в своем потоке.
А так - действительно, можно создавать один поток на 64 сокета...