GG
FWIW авторы Симулы - норвеги Ole-Johan Dahl и Kristen Nygaard
Хм. Вирт все равно молодец, но я думал, что он и к симуле руку приложил. Но спасибо за инфу
Size: a a a
2020 January 15
TS
С точки зрения ОС нет разницы, а с точки зрения пользователя либы есть, либо сопрограмма при старте запускается на любом из пула возможных потоков ос ( в процессе работы один из незанятых потоков может "украсть" задачу у другого потока ядра) или этого механизма нет и разработчик сам определяет где выполняется запущенная корутина (как бонус, сам перемещает её между потоками ос)
интересные вопросы задаёте, пока нет быстрого ответа. (Я не использую userver в повседневной жизни, так как мой проект - симулятор немного о другом). Насколько я понимаю в специфических сценариях типа postgress драйвера используется нижележащий threadpool.
Кажется (кажется) что таки и в общем режиме сопрограммы запускаются на фиксированном пуле boost::coroutines2::coroutine (не уверен, что разница тут большая).
Кажется (кажется) что таки и в общем режиме сопрограммы запускаются на фиксированном пуле boost::coroutines2::coroutine (не уверен, что разница тут большая).
TS
Лучше, конечно, вопросы самому Антону задавать. Я тут только болельщик
p
ну то есть, если мы не лезем в планировщик (а мы не лезем) и делаем сохранение контекста в user-space (при помощи boost::coroutine2), то какая технологическая разница между 1:N и M:N?
не любой код готов внезапно оказаться в другом потоке :)
AB
@lynxed что брать boost compute или cuda для нового проекта
ZO
@lynxed что брать boost compute или cuda для нового проекта
Я biased в этом вопросе
AB
Biased это кто ищи что ?
FC
Biased это кто ищи что ?
предвзятость
TS
@lynxed что брать boost compute или cuda для нового проекта
ставлю десятку рублей, что Злата (внезапно) порекомендует CUDA...
AB
Я biased в этом вопросе
Ты же знаешь преимущества перед opencl ?
ZO
Ты же знаешь преимущества перед opencl ?
Порекоммендуй хорошую статью?
AB
Сам пытаюсь разобраться
2020 January 16
A
интересные вопросы задаёте, пока нет быстрого ответа. (Я не использую userver в повседневной жизни, так как мой проект - симулятор немного о другом). Насколько я понимаю в специфических сценариях типа postgress драйвера используется нижележащий threadpool.
Кажется (кажется) что таки и в общем режиме сопрограммы запускаются на фиксированном пуле boost::coroutines2::coroutine (не уверен, что разница тут большая).
Кажется (кажется) что таки и в общем режиме сопрограммы запускаются на фиксированном пуле boost::coroutines2::coroutine (не уверен, что разница тут большая).
Если просто:
1. В случае когда мы одновременно работаем с тысячами/десятками тысяч одновременных соединений, мы регистрируем все сокеты в реакторе(epoll, если речь про Linux) и реакцию на события сети получаем через колбеки. Естественно нам в данном случае нет смысла задумываться о синхронизации доступа к разделяемым данным, если речь идёт о колбеках, вызываемых в контекте того потока, где выполняется epoll. В них вызовы всех обработчиков сериализованы.
2. Почему бы данное свойство(отсутствие необходимости использовать примитивы синхронизации) не использовать при работе с лёгкими потоками? На каждое соединение запускаем лёгкий поток, но так, чтобы он был привязан к конкретному физическому потоку OS. Но в отличие от п.1, у нас нет лапши колбеков с невнятным потоком управления и stack ripping'ом
Если нужно решить вопрос балансировки, перешедуливаем сопрограммы на другой тред OS
1. В случае когда мы одновременно работаем с тысячами/десятками тысяч одновременных соединений, мы регистрируем все сокеты в реакторе(epoll, если речь про Linux) и реакцию на события сети получаем через колбеки. Естественно нам в данном случае нет смысла задумываться о синхронизации доступа к разделяемым данным, если речь идёт о колбеках, вызываемых в контекте того потока, где выполняется epoll. В них вызовы всех обработчиков сериализованы.
2. Почему бы данное свойство(отсутствие необходимости использовать примитивы синхронизации) не использовать при работе с лёгкими потоками? На каждое соединение запускаем лёгкий поток, но так, чтобы он был привязан к конкретному физическому потоку OS. Но в отличие от п.1, у нас нет лапши колбеков с невнятным потоком управления и stack ripping'ом
Если нужно решить вопрос балансировки, перешедуливаем сопрограммы на другой тред OS
A
Если просто:
1. В случае когда мы одновременно работаем с тысячами/десятками тысяч одновременных соединений, мы регистрируем все сокеты в реакторе(epoll, если речь про Linux) и реакцию на события сети получаем через колбеки. Естественно нам в данном случае нет смысла задумываться о синхронизации доступа к разделяемым данным, если речь идёт о колбеках, вызываемых в контекте того потока, где выполняется epoll. В них вызовы всех обработчиков сериализованы.
2. Почему бы данное свойство(отсутствие необходимости использовать примитивы синхронизации) не использовать при работе с лёгкими потоками? На каждое соединение запускаем лёгкий поток, но так, чтобы он был привязан к конкретному физическому потоку OS. Но в отличие от п.1, у нас нет лапши колбеков с невнятным потоком управления и stack ripping'ом
Если нужно решить вопрос балансировки, перешедуливаем сопрограммы на другой тред OS
1. В случае когда мы одновременно работаем с тысячами/десятками тысяч одновременных соединений, мы регистрируем все сокеты в реакторе(epoll, если речь про Linux) и реакцию на события сети получаем через колбеки. Естественно нам в данном случае нет смысла задумываться о синхронизации доступа к разделяемым данным, если речь идёт о колбеках, вызываемых в контекте того потока, где выполняется epoll. В них вызовы всех обработчиков сериализованы.
2. Почему бы данное свойство(отсутствие необходимости использовать примитивы синхронизации) не использовать при работе с лёгкими потоками? На каждое соединение запускаем лёгкий поток, но так, чтобы он был привязан к конкретному физическому потоку OS. Но в отличие от п.1, у нас нет лапши колбеков с невнятным потоком управления и stack ripping'ом
Если нужно решить вопрос балансировки, перешедуливаем сопрограммы на другой тред OS
В go, к сожалению, этой возможности нет.
AA
A
не понятно при чём тут это
IB
Если просто:
1. В случае когда мы одновременно работаем с тысячами/десятками тысяч одновременных соединений, мы регистрируем все сокеты в реакторе(epoll, если речь про Linux) и реакцию на события сети получаем через колбеки. Естественно нам в данном случае нет смысла задумываться о синхронизации доступа к разделяемым данным, если речь идёт о колбеках, вызываемых в контекте того потока, где выполняется epoll. В них вызовы всех обработчиков сериализованы.
2. Почему бы данное свойство(отсутствие необходимости использовать примитивы синхронизации) не использовать при работе с лёгкими потоками? На каждое соединение запускаем лёгкий поток, но так, чтобы он был привязан к конкретному физическому потоку OS. Но в отличие от п.1, у нас нет лапши колбеков с невнятным потоком управления и stack ripping'ом
Если нужно решить вопрос балансировки, перешедуливаем сопрограммы на другой тред OS
1. В случае когда мы одновременно работаем с тысячами/десятками тысяч одновременных соединений, мы регистрируем все сокеты в реакторе(epoll, если речь про Linux) и реакцию на события сети получаем через колбеки. Естественно нам в данном случае нет смысла задумываться о синхронизации доступа к разделяемым данным, если речь идёт о колбеках, вызываемых в контекте того потока, где выполняется epoll. В них вызовы всех обработчиков сериализованы.
2. Почему бы данное свойство(отсутствие необходимости использовать примитивы синхронизации) не использовать при работе с лёгкими потоками? На каждое соединение запускаем лёгкий поток, но так, чтобы он был привязан к конкретному физическому потоку OS. Но в отличие от п.1, у нас нет лапши колбеков с невнятным потоком управления и stack ripping'ом
Если нужно решить вопрос балансировки, перешедуливаем сопрограммы на другой тред OS
о каком реакторе и колбеках здесь речь?
http://man7.org/linux/man-pages/man2/epoll_wait.2.html
http://man7.org/linux/man-pages/man2/epoll_wait.2.html
A
о каком реакторе и колбеках здесь речь?
http://man7.org/linux/man-pages/man2/epoll_wait.2.html
http://man7.org/linux/man-pages/man2/epoll_wait.2.html
Ну пусть проактор.
Всё равно и там и там внутри тред, который спит на epoll_wait и по результату после возврата управления имеем список сокетов и тех операций, которые мы готовы с ними сделать.
От stack ripping'а всё равно не избавиться в "классическом" подходе
Всё равно и там и там внутри тред, который спит на epoll_wait и по результату после возврата управления имеем список сокетов и тех операций, которые мы готовы с ними сделать.
От stack ripping'а всё равно не избавиться в "классическом" подходе
VL
В go, к сожалению, этой возможности нет.
какой конкретно возможности нет? Прибить горутину к треду?
VL
или большие хешмапы держать в стеке?