Ну в потоке если я while true сделаю, а потом

закрою прогармму, поток закроется сам или будет в памяти висеть?

дождаться его завершения, метод join

там while(true) какой дождаться?)

Поскольку поток это дочерний процесс то нет

А если detach() вызывался?

Это делает его не дочерним?

Перестаньте бредить, поток это не процесс

Я тебя удивлю

Не знаю, поэтому и спрашиваю)

Это делает его таким, будто он сам как программа

Не процесс жи

Мы не только про линукс говорим)

Верно. Ведь если ты запустишь программу из терминала, а затем закроешь терминал, ведь программа остановится, так? Это связано с тем, что терминал - родитель, а программа внутри него - дочерний процесс. Как бы то ни было, операционная система все разрушит и высвободит все ресурсы даже при аварийном завершении

Я не шарю как это в винде(ведь в теории также, только системные вызовы другие?), просто для лёгкого понимания рассказываю на такой аналогии

Нет, она в процессах висеть будет, можешь проверить

В винде иначе, и в общем случае, поток (thread) не является отдельным процессом, как это реализовано внутри ОС - не суть важно с точки зрения стандарта C++

Ну проверил, процесс завершился когда терминал закрыл. Сам проверь кек)

Дак ты напиши while true)

Обычно поток это что-то вроде процесса с одной виртуальной памятью с главным, но со своим стеком В винде это по-другому работает?(я за реализацию потоков в винде не шарю)

Хорош фантазировать и бредить. Всё определяется конкретной реализацией в конкретной либе для многопоточности. А там могут и на процессах сделать и не на процессах и вообще на кластере разных компов.

А я сказал обратное?

Да. Это обратное тому что ты сказал? Тут Илья в чате я не хочу флуд разводить

Да, а то сразу забаню!

Не закроется

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

Он прав...

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

Не надо этот юниксовый-линуксовый хлам тащить в общий чат по языку. Понятия процессов и потоков в операционных системах и с++ - разные, в с++ например процессов нет вообще.

Вот сейчас решил проверить. Я создал 8 потоков, в htop у них у всех разные process id. Как инaче?(ща в лс картинку с кодом отошлю)

как оно бывает по другому - читайте в доках MS

А, понял. Тогда да

Если ты работаешь в Linux, то ты должен знать то идентификатор процесса не только в htop А во многих других утилитах, на самом деле является идентификатором потока операционной системы.

Собственно то что ты описал это уникальная особенность Linux, ядра

Т.е. получается, если начну писать приложение под unix, linux, то не смогу организовать многозадачность? Как понимать процесс != поток, во всех умных книжках пишут для одноядерных процессоров процесс=потоку. Не силен в многопоточности, чтобы не было путаницы для новичков, лучше разъяснить вот эти моменты. Спор выше, конечно, был интересный, но больше запутал, чем дал однозначный ответ.

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

Если такое видишь где-то в книжке это очень плохая книжка видимо

Организовать конечно сможешь, потому что Современный Linux, современный unix, чаще всего в виде FreeBSD, они поддерживают многопоточность уже сейчас. Но изначально еë там не было

Что есть изначально? Многопроцессность и многопоточность были еще до собственно появления юниха и даже на одном ядре. Есть много вариантов, как и для чего ее делать. Например ОСРВ подход. Да и на однокристалках и сейчас ее реализуют и часто не POSIX.

"И сейчас ее реализуют и часто не POSIX"-вы пытаетесь утоить от нас ценную информацию. POSIX - наше все, если часто и не на POSIX, может пришлете ссылки на код в github, может в хороших книжках реализацию?

так и есть, но это псевдо многозадачность. И к сожалению процессоры работают не на магии, и пока что на смену задачи требуются ресурсы, поэтому плодить 100500 потоков не самая лучшая идея. В любом случае в итоге это все встанет в очередь и выполнится последовательно, но организация этого не твоя забота. Если ядра у цп 4, то и эффективно работать смогут 4 потока

Не пришлю, потому что не вижу смысла от нехер делать лазить в такие внутренности. Обычно просто юзаю то, что сделали разрабы платформы.

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

Не станет. Можно с учетом приоритетной очереди выдавать кванты времени твоим потокам выполнения. Можно через прерывания идти. И еще разного было напридумано. Но это читай уже сам.

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

Иди как почитай про это всё на других осях, особенно на старых.

А зачем старые оси, пора в мусорку выкидывать все. Оставим linux, macos, freebsd.

да, так и захотелось писать ПО под старые ос, зачем нам линукс и виндовс

Ну да - это будет весело.

Потому что разумно понимать, как оно всё это появлялось и почему, а не заучивать как библию.

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

Где там?

В операционках для DEC, VAX, IBM370, и так далее. Идея многопоточности не так уж стара.