LINUX.ORG.RU

fork


0

0

Извиняюсь что немного не в тему, но может кто подскажет: в винде форка совсем нету, или я просто не нашел ? CreateProcess не предлагать, хочется именно с того же места стартонуть, со всеми прочитанными конфигами и прочими данными в памяти.


Re: fork

похоже в win2k есть

anonymous ()
Ответ на: Re: fork от anonymous

Re: Re: fork

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

gennik ()

Re: fork

В мастдае нет fork'а. По этому он и мастдай (имел ввиду не только по этому конечно, но и по этому тоже).
Скорее всего для реализации своей задачи тебе придется использовать CreateThread() и все делать в одном процессе.

proff ()

Re: fork

Я хоть и НЕ мастдайщик, но форк is not advantage

anonymous ()

Re: fork

2 gennik - смешно ;)

2 last anonymous - а почему собственно is not advantage ? Удобно ведь.

2 proff Да видать прийдется, хотя так не хочется заморачиваться с тредами, все эти блокировки и т.д. Простая прога превращается в монстра

ignite ()

Re: fork

Юзай threads, они рулят.
После того как полюбишь их, fork() будешь использовать только в связке с exec().

alman ★★★ ()
Ответ на: Re: fork от alman

Re: Re: fork

Вот не надо ля-ля. Thread-ы во многих случаях либо избыточны, либо опасны. fork() часто оказывается наиболее правильным решением. Кроме того, ничто не мешает совмещать обе модели (шаренная память и COW). В общем, вопли "треды рулят, fork суксь" - один из первейших признаков безграмотности и ламеризьма, и с выдавшим подобное человеком продолать общение нет никакого смысла. Главное, других оградить от его вредных, зловонных излияний.

anonymous ()
Ответ на: Re: fork от alman

Re: Re: fork

Я нихочу никого обидеть, но предлагать использовать fork() только в связке с exec*() - расписываться в том, что задач, для которых "чистый" fork() критически необходим, - никогда не было даже в home work.
Плотно работая с нитками невольно соглашаешься с классиками: threads - самое дешевое и не самое изящное решение по реализации параллельности для SMP.

p.s. Главная головная боль при работе с нитками в долгоживущих процессах (читай демонах) - утечка ресурсов (читай памяти). Блокировки и синхронизация - это проблема стратегическая, т.е. решается на уровне проектирования, а вот утечка памяти - это проблема тактическая, программистская, с которой крайне эффективно борется fork(): нет дочернего процесса - нет проблеммы.

proff ()
Ответ на: Re: Re: fork от anonymous

Re: Re: Re: fork

Не городи чушь.
Не бросайся словами типа Copy-On-Write
Найди лучшее применние IPC.
Научись вежливо разговаривать со старшими.
И, возможно, тогда мы будем прислушиваться к твоему мнению.

Голословные утверждения, типа: "fork() иногда оказывется ниболее правильным решением" не стоит даже выеденного яйца, без указания ситуаций, когда применение fork() более оправдано. Хотя я не исключаю что такие ситуации есть.

Не называй чужие постинги воплями, отхватишь по полной. И ещё найди, _где_ я сказал что fork() sux???

alman ★★★ ()
Ответ на: Re: Re: fork от proff

Re: Re: Re: fork

Да, fork() зачастую решает проблемы утечки памяти. Кто-б спорил.
Однако утечка памяти есть признак плохой проектировки.

alman ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.