Наткнулся на странный пост, что якобы функция WSAPoll (winsock) не работает, как надо из-за внутренней ошибки. И, что более интересно, Майкрософт не хочет исправлять этот баг. Причем пишет не какой-то дурак, а вроде как уважаемый чел, автор Curl. Собственно https://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/ И тут обсуждение https://social.msdn.microsoft.com/F...cking-connects-to-nonexistent-ports?forum=wsk Как такое вообще может быть? Неужели такой архи-сложный баг? Или наоборот, не существенный.
Недавно столкнулся с тем что при асинхронном вводе-выводе WSASend/WSARecv эвент не работает. Если дождаться окончания обмена по эвенту и закрыть сокет, ничего не будет отправлено. Решение - оставлять сокет открытым
у мелкомягких есть некий пунктик об обратной совместимости с предыдущими версиями... может быть тут имеется ввиду, что гипотетически может существовать кодец, который юзает это поведение библиотеки в своих целях, поэтому они не могут просто это пофиксить... не говорю канеш, что так и есть, просто предположение... --- Сообщение объединено, 20 дек 2018 --- кстати у линуксов тоже бывает такая тема, наталкивался на примерно такой же момент... не помню конкретно, какая именно была функция в либси, но чисто условно в старых версиях была функция printf, у которой не обрабатывался какой-нить аргумент формата... так вместо того, чтобы в новой версии либси обновить функцию целиком, они запилили новую функцию образно __new_printf и в хедерах сделали дефайн printf на __new_printf... и если ты хочешь юзать старый printf, то тебе надо задефайнить у себя USE_OLD_PRINTF...
f13nd, видимо, тоже какая-то недоработка? Честно говоря, очень мало использовал асинхронные сокеты. Rel, может и так. Я вообще не слышал раньше про эту апи (хотя сеть знаю так себе, не идеально), и вот тут нашел пост. Насколько я знаю, линукс-разрабы любят использовать poll() , в винде тоже не помешал бы его адекватный аналог..
