если я хочу, чтобы мои корутины работали нормально — я должен обеспечить им работу в одном шедулере. один шедулер — это как раз и есть tokio, насколько я понял.
использовать токийный таймер на actix-rt ничто не мешает, но не появится ли у нас от этого два event loop в программе? я не в курсе, но, насколько я понял — это конкурирующие реализации экзекутора.
в go же доступ к шедулеру ограничен оператором
go
. внутри можно перепахивать все очень серьезно — например, в 1.14 появилась вытесняющая многозадачность — и на коде это не отразится никак.
криво реализованную фичу, которую в других языках спокойно используют в виде библиотеки.
я вот недавно выяснил, как реализовано это в виде библиотеки на rust (tokio). и оказалось, что, если ты хочешь, чтобы оно нормально работало, весь IO тебе надо делать на tokio, и всю синхронизацию на tokio, и все таймеры на tokio.
в этом свете решение внести эту функциональность прямо в runtime уже не выглядит таким уж кривым.
вот вы интервьюируете людей для сторонней компании. вас пригласили, как эксперта.
скорее всего, если вы твердо скажете «вот этого нанимайте» — его наймут, потому, что если уж ты позвал эксперта, его надо слушать.
если не скажете — точно не наймут. но будут задавать вопрос «а почему мы его не нанимаем»
и вот вы такой «общаетесь об опыте, о задачах, проектах».
и вам надо сказать «нанимайте», или «не нанимайте, потому что...», по результатам общания. и сказав «нанимайте» вы ставите на кон свою репутацию.
я, оказавшись пару раз в такой ситуации, решил свой опыт обобщить и формализовать.
а вы — обобщили и формализовали, или полагаетесь на интуицию?
если обобщили и формализовали — я очень хочу ознакомиться с результатами. потому, что собственная правота меня вообще не интересует, а интересует меня делать свою работу хорошо.
Неужели каждое обращение к каждой мапе триггерит некоторый детектор?
триггерит, да. детектор тривиальный, поэтому проблем не создает. но попытка чтения из map, в которую прямо сейчас происходит запись, закончится паникой. и это очень хорошо.
тут и близко нет про количество линз. тут все вопросы типа «как лазерный нивелир автоматически находит горизонталь» (лазер там в кардане подвешен, если что. и из этого следует, что рычажок фиксации надо передвигать в правильное положение при любой транспортировке, хоть на пару метров)
читать эту лапшу — вт что трудно
если я хочу, чтобы мои корутины работали нормально — я должен обеспечить им работу в одном шедулере. один шедулер — это как раз и есть tokio, насколько я понял.
использовать токийный таймер на actix-rt ничто не мешает, но не появится ли у нас от этого два event loop в программе? я не в курсе, но, насколько я понял — это конкурирующие реализации экзекутора.
в go же доступ к шедулеру ограничен оператором . внутри можно перепахивать все очень серьезно — например, в 1.14 появилась вытесняющая многозадачность — и на коде это не отразится никак.
я вот недавно выяснил, как реализовано это в виде библиотеки на rust (tokio). и оказалось, что, если ты хочешь, чтобы оно нормально работало, весь IO тебе надо делать на tokio, и всю синхронизацию на tokio, и все таймеры на tokio.
в этом свете решение внести эту функциональность прямо в runtime уже не выглядит таким уж кривым.
список, кстати, можно делать не только на указателях, но и на индексах массива. что решает проблему кешироания.
вот вы интервьюируете людей для сторонней компании. вас пригласили, как эксперта.
скорее всего, если вы твердо скажете «вот этого нанимайте» — его наймут, потому, что если уж ты позвал эксперта, его надо слушать.
если не скажете — точно не наймут. но будут задавать вопрос «а почему мы его не нанимаем»
и вот вы такой «общаетесь об опыте, о задачах, проектах».
и вам надо сказать «нанимайте», или «не нанимайте, потому что...», по результатам общания. и сказав «нанимайте» вы ставите на кон свою репутацию.
я, оказавшись пару раз в такой ситуации, решил свой опыт обобщить и формализовать.
а вы — обобщили и формализовали, или полагаетесь на интуицию?
если обобщили и формализовали — я очень хочу ознакомиться с результатами. потому, что собственная правота меня вообще не интересует, а интересует меня делать свою работу хорошо.
триггерит, да. детектор тривиальный, поэтому проблем не создает. но попытка чтения из map, в которую прямо сейчас происходит запись, закончится паникой. и это очень хорошо.
не понимать, что интервьюер имеет в виду под «развернуть» — нормально, и задать уточняющий вопрос тоже.
на вопрос «что такое односвязанный список» я тоже отвечаю, просто задаю чуть больше вопросов по алгоритму.
короче — нарисованная вами печальная картина в реальности не наблюдается :)
программист, который тупо делает, как научили, и не задумывается над смыслом — будет очень плохим программистом.
я разную обратную связь получал по докладу, но прям такую — в первый раз.