Насколько я понимаю, неблокирующие веб-серверы (node.js, eventmachine, tornado) могут остановиться, если они обратятся к блокирующей библиотеке. Верно ли это и для Голанга? Если одна горутина блокируется, другой автоматически получает доступ к ЦП, или им нужно ждать, пока заблокированная горутина «выдаст»? Если это первое, то библиотеки не должны быть неблокирующими, не так ли? Я спрашиваю, потому что я не видел ни одной библиотеки Redis/Mongo, в которой явно указано, что они неблокирующие.
Golang — должны ли библиотеки быть неблокирующими?
Ответы (1)
Насколько я понимаю, неблокирующие веб-серверы (node.js, eventmachine, tornado) могут остановиться, если они обратятся к блокирующей библиотеке. Верно ли это и для Голанга?
Нет, это не так. Подпрограммы Go будут уступать при вводе-выводе, или среда выполнения будет создавать новые потоки ОС по мере необходимости.
Если одна горутина блокируется, другой автоматически получает доступ к ЦП
Да, это так - подпрограммы go уступают любому типу ввода-вывода или канальной связи.
или они должны ждать, пока заблокированная горутина не «уступит»?
Нет, это не так.
Если это первое, то библиотеки не должны быть неблокирующими, не так ли? Я спрашиваю, потому что я не видел ни одной библиотеки Redis/Mongo, в которой явно указано, что они неблокирующие.
Никакие библиотеки (или код Go в целом) не должны быть неблокирующими, что значительно упрощает их написание и поддержку. На мой взгляд, это главный плюс Go. Среда выполнения делает умный шаг, запуская тысячи подпрограмм go, а вы просто пишете простой императивный код.
person
Nick Craig-Wood
schedule
24.07.2013
То есть, если горутина блокируется, она не блокирует весь поток (который используется совместно с другими горутинами)? Если это так, единственный раз, когда вам нужно написать код обратного вызова, — это когда вы хотите, чтобы эта конкретная горутина продолжалась, а не переключалась на другую (что, я думаю, довольно редко)?
- person tldr; 25.07.2013
Вы не используете обратные вызовы для этого. Вы поместите вещь, которая блокирует, в отдельную горутину, а затем используйте каналы, чтобы она могла ответить, когда это будет сделано.
- person Ask Bjørn Hansen; 25.07.2013
@Ник, твой тройной минус трудно понять, поясни, пожалуйста. (Нет библиотек...)
- person thwd; 25.07.2013
Хороший ответ, Ник. Нынешнее увлечение асинхронным вводом-выводом выросло из-за ограниченных возможностей различных сред выполнения, особенно JVM. Go значительно облегчает жизнь разработчикам, избавляясь от этого конкретного ограничения. (У Оккама схожие намерения)
- person Rick-777; 26.07.2013
@ Том, я думаю, он хотел поставить запятую после «Нет», то есть «Нет, библиотеки не должны быть неблокирующими». Библиотеки могут блокироваться, потому что даже если горутина блокируется, другие горутины все еще имеют доступ к ЦП. Это резко контрастирует с узлом, машиной событий, торнадо и т. д., где только один поток имеет доступ к ЦП и, следовательно, никогда не должен блокироваться.
- person tldr; 26.07.2013
