- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
for (int i = 0; i < 15; i++) {
// Прикольное место, надо прокомментировать
// Если наша функция Fork() вернула true, то мы
// в дочернем процессе и форкаться больше не надо
// Форканье - это задача родителя
// Дети этим заниматься не должны
if (Fork()) break;
}
bormand 07.01.2013 15:04 # +4
Чем бы дитя не тешилось, лишь бы не форкалось.
> Есть идеи, как улучшить?
Ну я в свое время, когда форкал процессы, вообще не возвращал управления из функции, подобной вашей Fork, в дочернем процессе:
myzone 07.01.2013 15:21 # +2
bormand 07.01.2013 15:29 # +1
myzone 07.01.2013 15:37 # 0
должен получать указатель еще указатель на пул и ставить в очередь этого пула
{@see ExecutorService}
bormand 07.01.2013 15:50 # 0
Ну по условиям моей задачи пул не требовался, а каждый раз нужен был новый процесс. Поэтому было реализовано именно так, а не иначе.
> должен получать указатель еще указатель на пул и ставить в очередь этого пула
Ну да, логично. Еще до кучи можно передать колбек, который вызовет пул, когда задача будет выполнена.
myzone 07.01.2013 15:59 # 0
ПС надо бы сделать rebase для коментов )
roman-kashitsyn 07.01.2013 16:08 # 0
Да, только тут процессы, а не потоки. В жабе такого из коробки нет. Вот за что люблю python - в нём есть решения практически на все случаи жизни:
myzone 07.01.2013 16:51 # 0
Тем более ExecutorService - интерфейс
roman-kashitsyn 07.01.2013 23:29 # 0
myzone 08.01.2013 01:23 # +1
3.14159265 09.01.2013 16:57 # 0
С этим будут основные проблемы.
>раздающий Future по Callable, используя пулл процессов.
Но действительно - зачем? Или я чего-то не пойму.
Потоки они ведь легковесные и проблем с ними меньше.
bormand 09.01.2013 18:45 # +2
Ну в винде да, разница на порядки. А вот в линухе емнип форк медленнее птред_крейта всего раза в 2.
А вообще - если хочется хорошей изоляции, надежности, и возможности запустить каждую задачу под соотв. юзером ограничив ей видимость своей папкой (аля андроид), а еще надо запускать недоверенный код (аля ideone)... то потоки вообще не вариант.
P.S. А с future на процессах я так понимаю основная проблема будет в маршаллинге. Все что не Serializable, и не сможет прокачаться через пайп, в такую фьючу не пропихнешь, и результатом не вытащишь.
P.P.S. Шаренная память в этом случае не особо вариант, т.к. если обмен идет через маленькое окно - те же самые траблы что у пайпа, только код сложнее. А если всю расшарить - ну тогда проще и юзать потоки.
roman-kashitsyn 09.01.2013 18:55 # +1
Именно. Необходимость сериализации данных между жабо-машинами ломает семантику ExecutorService, делая его реализацию на процессах просто невозможной. Ну и кросс-платформенное решение возможно, скорее всего, только при допиливании jre.
bormand 09.01.2013 19:56 # 0
3.14159265 09.01.2013 19:18 # 0
SecurityManager
> и возможности запустить каждую задачу
> ограничив ей видимость
Для ряда задач можно использовать ClassLoaderы. Правда там свои подводные камни.
bormand 09.01.2013 19:54 # 0
Не жабой единой... все-таки тема этого раздела С++.
P.S. А SecurityManager спасёт от OutOfMemoryError?
P.P.S. В ведре есть нативные приложения и JNI, поэтому, видимо, они и не стали заморачиваться с менеджером безопасности, и сделали по юзеру на каждое приложение.
3.14159265 09.01.2013 20:14 # +3
По меркам этого сайта мы не сильно ушли от темы :)
3.14159265 09.01.2013 20:39 # +1
Хороший вопрос. Мне на ум приходят только разные извраты. Не буду озвучивать.
Очень хороший. Много думал. Наверное никак. Жаба сама по себе песочница, и они считают что риска для остальной системы нет.
>нативные приложения и JNI
Ну вот как раз для них оно и придумано. Все внешние обращения (в т.ч. LoadLibrary) там мониторятся.
А вот память кагбе внутренний ресурс JVM, который ограничен при запуске.
bormand 09.01.2013 21:47 # 0
Ну вот поэтому для недоверенного кода и нужны процессы ;(
Иначе из-за одного неудачного треда, который (возможно непреднамеренно, из-за бага) выжрет всю память, просто распидорасит всю JVM вместе с невиновными тредами, которые тихо и мирно выполняли свою работу. Куча то у них общая.
> Все внешние обращения (в т.ч. LoadLibrary) там мониторятся.
И приходится либо убирать возможность запуска нативных программ и либ (т.к. с ними уже никакой секурити манагер не справится), как поступили в браузерах, или забить на менеджера безопасности, сделать по юзеру на прогу и запретить им лазить друг к другу, как поступили на ведре.
3.14159265 10.01.2013 15:52 # 0
Хорошо, а как в других языках (тот же питон с пулом и мультипроцессами) решить такую задачу - поставить квоту на цп, память процесса?
defecate-plusplus 10.01.2013 18:02 # +1
в винде есть Job Objects
bormand 10.01.2013 20:57 # 0
Ну его можно сделать при желании.
> в винде есть Job Objects
А в линухе есть setrlimit.
Так что хоть и os specific, но, по идее, можно на всех приличных осях...
P.S. Если же запускать жабомашины - то можно в параметрах и указать лимит памяти, получится более-менее кроссплатформенное решение. С CPU - хз.
3.14159265 10.01.2013 21:13 # 0
> В жабе такого из коробки нет.
> осилит реализовать жабий ExecutorService, кроссплатформенно используя пулл процессов.
А в питоне есть такое кроссплатформенное решение "из коробки", которым можно ставить квоты по памяти на запускаемые процессы?
Других разумных применений такому расточительству как пул потоков я пока не вижу.
defecate-plusplus 11.01.2013 09:24 # 0
ну этот виндовый Job Objects умеет в ограничение CPU только чуть ли не с Шиндошс-8 только (http://bit.ly/VOXWJJ), а в XP - только ограничить user-time + sheduling class
собсно, setrlimit, судя по ману недалеко ушел от XP (RLIMIT_CPU + RLIMIT_NICE)
bormand 11.01.2013 10:45 # 0
А так ли нужно это ограничение? Имхо достаточно искусственная вещь. При правильно розданных scheduling class'ах и так все будет нормально делиться, к тому же проц не будет зазря простаивать, если нет более приоритетной работы. Х.з. конечно, может быть я и ошибаюсь.
someone 07.01.2013 16:22 # +1
А так нормальное решение, почему бы нет?
kafeman 07.01.2013 17:43 # +1
bormand 07.01.2013 18:26 # +3
Главное не забывать задокументировать где она стоит, что делает, и, по возможности, как. А то потом случаются не очень приятные истории, когда весь отдел сидит и пытается понять, нужен ли кому-то демон, конфиги и исходники которого последний раз правились лет 7-8 назад...
Dummy00001 07.01.2013 21:06 # 0
для *нихов это не костыль, это нормально. у меня где-то валяются сырцы сервера с пре-форком - там форк в самом условии while() вызывается. выглядит феерично, но суть та же: надо просто процессов дочерних процессов нафоркать, которые тупо в accept()е ждут запросов от клиентов.
> Лучше пулы юзать.
зависит от задачи. для многих простых вещей пул только усложнит программу. относительно плохая(*) производительность форка становится критичной только если делаешь что-то большое.
(*) относительно потоков.
myzone 08.01.2013 01:28 # +1
Да и вообще мне не особо понятно зачем плодить процессы, если есть специально придуманные потоки? Единственный юзкейс, который я знаю - создание полной независимости частей приложения, табы в хроме, например.
Dummy00001 08.01.2013 01:48 # 0
фишка fork() как раз в том что его можно сделать легковесным. что почти все *нихи и делают. copy-on-write уж как лет десять везде реализован.
vfork() - я как бы и не уверен что он еще жив. сама идея vfork() была убогой. на паре *нихов и линухе это просто алиас для fork() потому что создание копии vma уже в самом fork() сделано ленивым.
ЗЫ vfork() в POSIX.6 - deprecated, POSIX.7 - non-existent.
ЗЗЫ линух реализовал vfork()! правда то как он работает это совсем не BSD vfork() - http://www.kernel.org/doc/man-pages/online/pages/man2/vfork.2.html
myzone 08.01.2013 01:55 # 0
А вообще я в качестве лабы по ОС писал простенький веб-сервер, так вот, смена fork на vfork дала прирост производительности... О подробностях ничего не знал.
Dummy00001 08.01.2013 02:09 # 0
только что еще раз проверил. AIX и Линух - нету vfrok. (непортабельный линуховый vfork() не в счет.)
HP-UX & Solaris - есть, но (по традиции) зарезервирован только для последующего вызова exec() (но для HP-UX я точно видел официальное указание что разницы с fork()ом нету). та же песня в FreeBSD, но с нытьем в манпэйдже которое намекает что гондурасы все еще lazy vma copy не сделали: "The vfork() system call can be used to create new processes without fully copying the address space of the old process, which is horrendously inefficient in a paged environment."
myzone 08.01.2013 02:18 # 0
Dummy00001 08.01.2013 02:27 # 0
guest6 04.09.2023 19:23 # 0
Desktop 04.09.2023 19:45 # 0
ты по меркам этого треда кинул ссылку на далёкое светлое будущее
bormand 08.01.2013 07:33 # 0
Изоляция. Можно запустить часть детей под нужным юзером, родитель не крашится при поломке одного ребенка и т.п. Часто ради этого приходится жертвовать производительностью. Хотя в линуксе время форка и время создания потока не сильно отличаются, в отличие от винды, где разница на порядки.
> Лучше уже vfork тогда
vfork, если мне не изменяет память, можно юзать только в сочетании с exec, по отдельности он бесполезен:
vfork() differs from fork(2) in that the parent is suspended until the child terminates (either normally, by calling _exit(2), or abnormally, after delivery of a fatal signal), or it makes a call to execve(2). Until that point, the child shares all memory with its parent, including the stack.
myzone 08.01.2013 09:34 # 0
vfork уже выше обсудили, так что Вы опоздали )
bormand 08.01.2013 09:38 # 0
myzone 08.01.2013 09:42 # 0
bormand 09.01.2013 15:39 # 0
myzone 09.01.2013 18:59 # 0
myzone 08.01.2013 10:12 # 0
bormand 09.01.2013 15:49 # 0
Мда. И правда не блочит. Не зря там ниже написано: In particular, the programmer cannot rely on the parent remaining blocked until the child either terminates or calls execve(2), and cannot rely on any specific behavior with respect to shared memory..
Т.е. походу vfork можно юзать перед exec, чтобы получить небольшое ускорение на старых системах. А на новых он тупо ничем не отличается от fork.
UPD: сейчас переделаю тест, clock же измеряет не реальное время, а процессорное.
bormand 09.01.2013 16:10 # 0
На моей машине выдает вот такое: Т.е. в vfork блокировка есть, в fork ее нет.
Ваш ход.
tirinox 07.01.2013 23:22 # +3
Dummy00001 08.01.2013 02:30 # +2
absolut 08.01.2013 10:31 # 0
Хорошо, что не свои глаза.
Lure Of Chaos 08.01.2013 02:28 # +2
zim 08.01.2013 10:06 # +3
absolut 09.01.2013 14:44 # +2
p.s. интересно, страйко постарался или оно само восстанавливается?
scriptin 09.01.2013 21:33 # 0