я не знаю почему, но это реально дурацкое решение

просто у v8 вроде бы есть (точно была) такая "замечательная" особенность, как строго один интерпретатор на процесс

ну то есть как в питоне

в чем основное отличие тредов от процессов?

шаред мемори

при желании можно сделать

в чем основное отличие тредов от процессов?

в отсутствии необходимости дополнительных механизмов шаринга памяти

ну то есть как в питоне

серьёзно?

серьёзно?

серьезно

типа я не могу сделать два инстанса питона в одном процессе?

типа я не могу сделать два инстанса питона в одном процессе?

неа, по крайней мере, не в cpython

шо?

вот кого за это винить?

вот кого за это винить?

поплачься в мейлинг лист :)

с питоном то ладно, у него какие-никакие потоки есть

гхм... а зачем?

ты не один такой

типа я не могу сделать два инстанса питона в одном процессе?

Зачем?

а воркеры - это, вроде, процессы

Эм. Вот хз насчёт процессов

но вот в v8 зачем так сделали непонятно вообще

в отсутствии необходимости дополнительных механизмов шаринга памяти

на самом деле в линуксе разницы ваще нет. Можно при желании сделать "тред", имеющий общую память с родителем, но не имеющий доступа к файловой системе

гхм... а зачем?

ну, можно было бы запускать по интерпретатору на поток, а дальше выкинуть GIL... но это утопия

разные наборы флагов при создании

ну, можно было бы запускать по интерпретатору на поток, а дальше выкинуть GIL... но это утопия

Так запускай процессы, какая разница тебе

ну, можно было бы запускать по интерпретатору на поток, а дальше выкинуть GIL... но это утопия

мне сложно представить класс задач где подобное было бы оправдано.

на самом деле в линуксе разницы ваще нет. Можно при желании сделать "тред", имеющий общую память с родителем, но не имеющий доступа к файловой системе

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

не, я не про то

что именно аллокейтится задается флагами

мне сложно представить класс задач где подобное было бы оправдано.

любой, где хочется легковесные воркеры, как в го или эрланге

мне сложно представить класс задач где подобное было бы оправдано.

мне для v8 легко представить такой класс задач

он о том что процессы и потоки в линуксе реализуются почти одинаково

с одним флагом ты получишь "тред", с другим "процесс", а с третьим вообще что-то невообразимое

через вызов сисколла clone()

что именно аллокейтится задается флагами

ну, а еще для процесса используется fork()/exec(), а для потока - pthread_create()

они оба внутри используют clone

с разным набором флагов

они оба внутри используют clone

ну так-то да

оверхед при создании процесс в копировании таблицы страниц.

ну, можно было бы запускать по интерпретатору на поток, а дальше выкинуть GIL... но это утопия

А данными как обмениваться? Пиклами перекидываться?

хотя кстати я читал, что нода вроде позволяет относительно безболезненно поменять движок

А данными как обмениваться? Пиклами перекидываться?

shared memory \ sockets \ fifo?

А данными как обмениваться? Пиклами перекидываться?

как вариант, почему нет

его может не быть - таблица страниц может быть подготовлена заранее

даже не так, она все равно будет сделана

просто в случае "процесса" там будет copy-on-write флаг проставлен

хотя кстати я читал, что нода вроде позволяет относительно безболезненно поменять движок

ну, на деле ее еще только поверх майкрософтовского запускали вроде

во во

как вариант, почему нет

С тем же успехом можно запустить несколько процессов

но тут чужой мир, я не знаю деталей

С тем же успехом можно запустить несколько процессов

не с тем же, если у тебя есть шаред мемори

и move()

не с тем же, если у тебя есть шаред мемори

Шаред мемори и между процессами есть

более корректно будет сказать что потоки разделяют общее адресное пространство

Шаред мемори и между процессами есть

только если явно создашь

(parent/child не считаю)

Надо - создаешь, не надо - не создаешь. Профит все еще непонятен

Шарить объекты между тредами все равно не получится из-за того, что гила нет

Шарить объекты между тредами все равно не получится из-за того, что гила нет

смотря какие объекты и как шарить

более корректно будет сказать что потоки разделяют общее адресное пространство

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

Надо - создаешь, не надо - не создаешь. Профит все еще непонятен

ну, я пробовал работать с шаред мемори на сишке. Это много боли

смотря какие объекты и как шарить

Питоновские. Со счетчиком ссылок, предками и всем таким

Питоновские. Со счетчиком ссылок, предками и всем таким

ну, формально тут как раз нужна спецификация для move()

ну, я пробовал работать с шаред мемори на сишке. Это много боли

Если это спрятано глубоко внутри, пользователя это не волнует

чтобы передавать овнершип объекта в другой поток

Если это спрятано глубоко внутри, пользователя это не волнует

мы же сейчас про проблемы инженеров, а не пользователей?

пользователю вообще срать, потоки там или процессы

чтобы передавать овнершип объекта в другой поток

Опять же, надо делать по копии для каждого потока либо делать все иммутабелбным

пользователю вообще срать, потоки там или процессы

Ну есть еще ulimit

Опять же, надо делать по копии для каждого потока либо делать все иммутабелбным

И получишь ерланг

ну, я пробовал работать с шаред мемори на сишке. Это много боли

не особо много. Просто надо еще и синхронизацию руками делать

ладно, я офф, через час баиньки уже

Сложно это software transactional memory, а с общей памятью разобраться можно

Опять же, надо делать по копии для каждого потока либо делать все иммутабелбным

я боюсь соврать, не знаю тонкостей, но что мешает передавать в соседний поток уникальный указатель на шаред мемори?

как делают в C++

я боюсь соврать, не знаю тонкостей, но что мешает передавать в соседний поток уникальный указатель на шаред мемори?

Передать-то можно. Но менять его и то, что достижимо из него по ссылкам, сможет только один, иначе надо будет локами обмазываться

А это еще медленнее, чем гил

А это еще медленнее, чем гил

гил и есть лок

но вообще как работает unique_ptr?

Он работает в одном потоке

да, но ты можешь его передать в другой поток

Но тогда я сам должен о нем забыть

Но тогда я сам должен о нем забыть

ты с auto_ptr не путаешь?

разумеется

ты с auto_ptr не путаешь?

Не путаю

или я не понял проблему

в этом и суть избегания одновременного доступа

Не путаю

как ты передшь unique_ptr в другой поток?

А объект указывает на свой класс, а класс на много чего еще, и этому всему иногда хочется менять рефкаунт. Причем хочется и нам, и ему

ничосе развили тему

То есть все внутренности питона надо копировать

как ты передшь unique_ptr в другой поток?

std::move?

В С++ лок фри shared_ptr уже долго не могут сделать. Потому что сложно

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

Не только о нем, а обо всем, на что он ссылается. Либо менять ссылки, но это называется запиклить и отправить

как в питоне это делается?

std::move, кстати, ничего не делает, он просто кастует к rvalue-ссылке