Он за одну итерацию должен все скинуть туда (в свой буфер)

Вот так вот, бывает что не за одну итерацию

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

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

Это маловероятно.

Если у тебя, разви что, буфер будет 100Кб

Но я бы все равно делал за один проход

Так и код будет проще

И понимание кода улучшится

Ну ты же так не будешь доделывать работу фактически

Да и такая вероятность мала..

Лучше уж дописать туда по максимуму пока есть возможность

Лучше уж дописать туда по максимуму пока есть возможность

Это и есть блокирующий режим

Ты же пытаешься пистаь асинхронный код

Да и такая вероятность мала..

Слушай тут странно рассуждать о вероятностях. Я у себя по трейс логам все эти кейсы видел. Очень нередко данные в сокет пишутся за 3-4 захода по 500-1000 байт

Иногда в 1 заход 4Кб бывает

Если у тебя, по какой-то не понятной причине, буфер вышел 100Кб и сокет СВЕРХ быстрый и успивает ВСЕ скинуть!

То ты и будешь зависать там...

На проде все эти проблемы усилились, в реальных интернетах сокеты гораздо медленнее чем на локалхосте

На проде все эти проблемы усилились, в реальных интернетах сокеты гораздо медленнее чем на локалхосте

А что если ты в файл пишешь? Который на tmpFs?

Это твое дело

То ты и будешь зависать там...

Если будет огромный буфер то да, но 4кб буфер это разумная альтернатива Если мы его полностью записали в сокет, то можно пойти поработать над остальными событиями

Но лично я бы это делал за раз. Если за раз он больше не принял - значит буфер сокета не готов больше принять

Если будет огромный буфер то да, но 4кб буфер это разумная альтернатива Если мы его полностью записали в сокет, то можно пойти поработать над остальными событиями

А если нет - ты продолжаешь его долбать

Он же по какой-то причине больше не взял

А не из-за того, что просто соседний процесс начал писать что-то куда-то

Сам посуди

Хрен его знает...

Может ты и прав

Я не тестил

Я не тестил

Зато сообщений написал целую гору) а нам это читать приходится

https://github.com/andikleen/eproxy/blob/master/eproxy.c#L235 вот тут в цикле пишем пока пишется, во всех других реализациях тоже.

https://github.com/nginx/nginx/blob/008e9caa2a5b784d337422f1dc4290edfb9cc640/src/os/unix/ngx_files.c#L31

Сысоеву я верю...

Я не вижу вычитываний в цикле

Сколько прочел в буфер - столько прочел. Значит больше нет

И это верно

https://github.com/nginx/nginx/blob/008e9caa2a5b784d337422f1dc4290edfb9cc640/src/os/unix/ngx_files.c#L193

Но писать - он пишет в цикле

А что конкретно делает эта функция и при каких условиях ? Там какие то aio, треды

Но при этом он принемает по сколько писать в этот стрим

Оформляй крсиво и делай либу

есть способ избежать того факта, что try-catch-finally образует собственный scope?

у меня переменные внутри try открывают файлы, catch ловит файловые исключения, но переменые потом не видать извне. есть способ этого избежать окромя объявления этих переменных сразу снаружи?

Объявить их снаружи. Не?

Объявить их снаружи. Не?

а кроме?

а кроме?

Никак

А в чем проблема то?

Сделай 2 трая

Если ты уверен, что исключение не при открытии файла

Как дебагер запустить под шиндовс 7 в VSCode?

Я в линуксе то не смог

у меня переменные внутри try открывают файлы, catch ловит файловые исключения, но переменые потом не видать извне. есть способ этого избежать окромя объявления этих переменных сразу снаружи?

Не нужно так делать - делай их внешними, это правильно идеологически

Не нужно так делать - делай их внешними, это правильно идеологически

А каково обоснование этой идеологии?

А каково обоснование этой идеологии?

даже лень объяснять блоки кода бесплатны и хорошо если их будет побольше

А каково обоснование этой идеологии?

А зачем они тебе в кетче?

А зачем они тебе в кетче?

чтобы писать не myClass obj; try { obj = new myClass(..); } catch(...){...} а сразу try { auto = new myClass(..) } ...

Это я понял

Зачем они тебе в кетче?

Ну у тебя ж конструктор наверное не кидает исключений?

можешь и вне кетча написать auto obj = new myClass()

Ну у тебя ж конструктор наверное не кидает исключений?

кидает, причём гору различных исключений

кидает, причём гору различных исключений

Ну допустим

Но в кетче то тебе зачем он тогда?

Если ты не помжешь его даже создать без 100% гарантии?

ну окей, это логично

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

мне тогда просто непонятно, что происходит на этапе myClass obj; и что из себя этот obj представляет, особенно учитывая, что у myClass нет пустого конструктора.

ERROR: S client not available

это тогда просто .... указатель? или что?

ссылка?

null?

Я затрудняюсь ответить, что там будет

Не делал так :)

Да там вроде будет null

так делать не надо, но, скорее всего, там будет null

Ну можно проверить (obj is null)

Подобная конструкция нужна для того, если ты присваиваешь (создаешь) туда разные объекты. Скажем в зависимости от входного параметра:

User obj; if (var >= 5) { obj = new UserLop(); }else{ obj = new UserTest(); }

вот тебе прям кусок кода SerialPort standCOM, PSICOM; SC config; try { config = readStruct!SC(configFileName); standCOM = new SerialPort(config.stand_COM.path, config.stand_COM.baud, config.stand_COM.mode); PSICOM = new SerialPort(config.PSI_COM.path, config.PSI_COM.baud, config.PSI_COM.mode); } catch (FileException fe){ stderr.writeln("Config file parsing error! ", fe.msg); return 2; } catch (SerialPortException spe){ stderr.writeln("Failed to open one or both COM ports: ", spe.msg, " Maybe try run with `sudo`?."); return 3; }

Подобная конструкция нужна для того, если ты присваиваешь (создаешь) туда разные объекты. Скажем в зависимости от входного параметра:

Есть лучшие предложения по реализации?

В примере выше я не вижу смысла выносить из try

Пусть будет все в одном месте

Имхо

Пусть будет все в одном месте

а потом config и оба COM-a используются

и в случае если они в try, их потом не видать снаружи

Конечно

Если ты хочешь продолжать работать с ними - ты обязан и последующий код пистаь в try

Иначе нет гарантий, что они создались

Иначе нет гарантий, что они создались

есть, потому что если они не создались, мы вылетаем напрочь из main

try { config = readStruct!SC(configFileName); standCOM = new SerialPort(config.stand_COM.path, config.stand_COM.baud, config.stand_COM.mode); PSICOM = new SerialPort(config.PSI_COM.path, config.PSI_COM.baud, config.PSI_COM.mode); } catch (FileException fe){ stderr.writeln("Config file parsing error! ", fe.msg); } catch (SerialPortException spe){ stderr.writeln("Failed to open one or both COM ports: ", spe.msg, " Maybe try run with sudo?."); }

И вот ты уже не вылетаешь

Но объектов нет

ну окей, но мне потом надо на 2 потока разваливаться

тоже внутри try?

Конечно компилятор может это найти и обработать...

Ну смотри

Ну а если они не создались и ты попытаешься с ними работать? Будет ошибка

Я точно не знаю как принято в С/С++. Но бросать исключения/ошибки в конструкторе - плохая затея

Что там у сборщика будет - хрен его знает

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