Здравствуйте, ksandro, Вы писали:
K>А вот мне скорее нравится, когда тестовые задания дают на дом. По крайней мере у меня с ними обычно не возникает больших проблем.
Вот когда человеку 22-25 и нет никаких забот и увлекаешься только программированием, тогда да, это может приносить удовольствие, а как бонус еще и работу более лучшую найдешь
а когда при открытии резюме тебе за неделю прилетает 300-500 предложений, да еще есть семья с детьми и увлечения кроме программинга то тратить 3-4 вечера плотно сидя над одной задачей это уже непозволительная роскошь, слава богу времена когда на одно место претендовали 10 человек прошли и пока таких жертв чтобы заработать приносить не надо
Исключения конечно есть, если меня например будут звать на позицию с зп 1млн+ то наверно соглашусь, но такие конторы обычно такой ерундой не занимаются
а задачки когда желание есть можно порешать и так, без сроков и интервьеров над душой
Здравствуйте, a.v.v, Вы писали:
AVV>а когда при открытии резюме тебе за неделю прилетает 300-500 предложений, да еще есть семья с детьми и увлечения кроме программинга то тратить 3-4 вечера плотно сидя над одной задачей это уже непозволительная роскошь, слава богу времена когда на одно место претендовали 10 человек прошли и пока таких жертв чтобы заработать приносить не надо
Из этих "300-500 предложений" только 3-5 будут от известных компаний. Ну, тех компаний, наличие которых в резюме будет полезно в дальнейшем. В итоге весь поиск так или иначе сведётся к выбору из крайне небольшого количества вариантов и попыток туда попасть.
С сетями еще не очень плотно взаимодействовал. Недавно на select сделал сервер.
Там единственный сокет listener, который bind'ится и слушает. На него приходят подключения и с которого они accept'ятся.
Далее эти новые сокеты кладутся в набор, который кладём в select.
А здесь сразу создаются много сокетов. Все они listen и bind. Что это за подход такой? Объясните, пожалуйста.
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, Pitirimov, Вы писали:
P>>все ядра процессора будут загружены работой из-за независимой, многопоточной обработки запросов и кэши каждого из ядер процессора не будут вымываться, потому что каждое ядро процессора будет обрабатывать свой поток с нужными только этому потоку данными. AJD>Как гарантировать, что поток будет постоянно работать на одном и том же ядре? Руками выставлять thread affinity?
Плюс, если потоков > ядер, конечно же, будет постоянный context switch.
Здравствуйте, Pitirimov, Вы писали:
P>Образцовый сервер из книги писал лохопед и вот почему: если хотя бы в одном из входящих соединений со стороны пользователя начнут принимать данные очень медленно, скажем, по байту в секунду, то запросы других пользователей к серверу будут ждать обработки очень и очень долго.
poll выдал данному сокету, что пришли данные.
В цикле дошли до него. Вычитали сколько есть. Какое еще ожидание по 1му байту в секунду?
Пошли в цикле к другому сокету.
и т.д.
Затем снова в poll. https://www.ibm.com/docs/en/zos/2.4.0?topic=functions-read-read-from-file-socket Behavior for sockets: The read() call reads data on a socket with descriptor fs and stores it in a buffer. The read() all applies only to connected sockets. This call returns up to N bytes of data. If there are fewer bytes available than requested, the call returns the number currently available. If data is not available for the socket fs, and the socket is in blocking mode, the read() call blocks the caller until data arrives. If data is not available, and the socket is in nonblocking mode, read() returns a -1 and sets the error code to EWOULDBLOCK. See ioctl() — Control device or fcntl() — Control open file descriptors for a description of how to set nonblocking mode.
Здравствуйте, kaa.python, Вы писали:
KP>Из этих "300-500 предложений" только 3-5 будут от известных компаний. Ну, тех компаний, наличие которых в резюме будет полезно в дальнейшем. В итоге весь поиск так или иначе сведётся к выбору из крайне небольшого количества вариантов и попыток туда попасть.
я никогда не гонялся за строчками в резюме, и если под известными компаниями понимается FAANG, Яндекс и прочее такого же рода, то не надо
есть целая куча достаточно интересных проектов и без этих фабрик и зп более менее адекватные, так что выбор намного шире
Здравствуйте, avovana, Вы писали: A>poll выдал данному сокету, что пришли данные. A>В цикле дошли до него. Вычитали сколько есть. Какое еще ожидание по 1му байту в секунду? A>Пошли в цикле к другому сокету. A>и т.д. A>Затем снова в poll.
Даже если входящие данные быстро вычитали, то затем с этими данными что делать? Быстро выкинуть прочитанные данные и идти к следующим? Время обработки вычитанных данных одного пользователя будет задерживать обработку данных других пользователей. В многопоточном сервере каждый пользователь обрабатывается независимо в своём потоке, поэтому время обработки данных каждого пользователя будет меньше даже на одном процессорном ядре.
Здравствуйте, Pitirimov, Вы писали:
P>Даже если входящие данные быстро вычитали, то затем с этими данными что делать? Быстро выкинуть прочитанные данные и идти к следующим? Время обработки вычитанных данных одного пользователя будет задерживать обработку данных других пользователей. В многопоточном сервере каждый пользователь обрабатывается независимо в своём потоке, поэтому время обработки данных каждого пользователя будет меньше даже на одном процессорном ядре.
Здравствуйте, Pitirimov, Вы писали:
P>Даже если входящие данные быстро вычитали, то затем с этими данными что делать? Быстро выкинуть прочитанные данные и идти к следующим? Время обработки вычитанных данных одного пользователя будет задерживать обработку данных других пользователей. В многопоточном сервере каждый пользователь обрабатывается независимо в своём потоке, поэтому время обработки данных каждого пользователя будет меньше даже на одном процессорном ядре.
Здравствуйте, Pitirimov, Вы писали:
P>Даже если входящие данные быстро вычитали, то затем с этими данными что делать? Быстро выкинуть прочитанные данные и идти к следующим?
В исходной задаче нужно возвращать hash строки. Так что да, вычитали и выбросили. Усложнение с многопоточкой чревато потерями на синхронизации. Нужно замерять скорость, так с теории "будет быстрее"- неочевидно.
Здравствуйте, Тёмчик, Вы писали: Тё>В исходной задаче нужно возвращать hash строки. Так что да, вычитали и выбросили. Усложнение с многопоточкой чревато потерями на синхронизации. Нужно замерять скорость, так с теории "будет быстрее"- неочевидно.
Я исходил из предположения, что обработка входящих данных пользовательских запросов рано или поздно потребует медленного ввода-вывода с жёсткого диска или сети. А раз так, то во время ожидания ввода-вывода при обработке данных одного пользователя многопоточный код обрабатывает данные других пользователей, поэтому многопоточный сервер уверенно должен обогнать по времени обработки данных однопоточный, который будет тупо обрабатывать пользователей одного за одним. Замеров времени обработки данных я не проводил, так как мне всё ясно и без них.
Здравствуйте, Pitirimov, Вы писали:
P>Даже если входящие данные быстро вычитали, то затем с этими данными что делать? Быстро выкинуть прочитанные данные и идти к следующим? Время обработки вычитанных данных одного пользователя будет задерживать обработку данных других пользователей. В многопоточном сервере каждый пользователь обрабатывается независимо в своём потоке, поэтому время обработки данных каждого пользователя будет меньше даже на одном процессорном ядре.
Вот то что я выделил почти всегда плохая идея. Пул потоков — да, опция и часто хорошая, но вот по потоку на пользователя это вообще ни в какие ворота.
