копирование/переименование файла c изменением названия по маске (чтобы не писать его 2 раза)
$ cp /path/to/file.txt{,.backup}
результат — /path/to/file.txt и /path/to/file.txt.backup
$ mv /path/to/file.{txt,log}
результат — /path/to/file.log
Вот именно, что нельзя юзать родительский коннект, и вы решили не побороть проблему, а обойти ее путем перекладывания всей работы с базой в родителя
>> родительский процесс должен заниматься базой и дочерние процессы делать «черную работу» и возвращать результат
т.о. получаются следующие ограничения
во-первых, потомки не могут полноценно работать с базой (транзакции и все такое)
во-вторых, и это очень важно, перекладывая работу с базой на один поток, мы лишаемся всех преимуществ многопоточной работы, ведь согласитесь, 16 потоков на 16 процах писали бы в базу гораздо быстрее чем один
в-третьих, когда все потомки отработали и передали данные в родителя для записи в базу, ему нужно все эти данные записать по-очереди, и пока он пишет, он не может запустить еще потомков, ну либо тут нужно организовывать какую-то асинхронную очередь для их обработки
в общем сплошные минусы, а решение то на самом деле элементарное — сразу после форка сбрасывать коннект и соединяться заново, а родителю перед его запросами проверять — не разорван ли его коннект и пересоединяться если нужно
не совсем понятно как ваш метод будет работать с транзакциями, когда нужно параллельно обрабатывать несколько потоков данных и каждый в своей транзакции, если у вас только один коннект к базе в родительском процессе. Т.е. подразумевается что любой поток может упасть и откатить транзакцию без вреда для остальных
нет, в данном случае было что сами файлы вообще не модифицировались,
т.е. делали эксперимент — создавали пустой файл, обзывали его test.php — в итоге в браузер приходил img
Из теорий почему так происходило было в основном — либо какой-то демон поселился на сервере и переписывал выдачу апача, либо контент перехватывался где-то по пути с сервера
у нас было еще веселее — периодически все php скрипты (даже пустые) приходили со встроенным в самое начало кода img со ссылкой на JS троян, хотя сами файлы были чистыми )
две недели общались с хостером, так и не выяснили в чем дело, однако через 2 недели все прошло
php-memcache нет
$ cp /path/to/file.txt{,.backup}результат — /path/to/file.txt и /path/to/file.txt.backup
$ mv /path/to/file.{txt,log}результат — /path/to/file.log
>> родительский процесс должен заниматься базой и дочерние процессы делать «черную работу» и возвращать результат
т.о. получаются следующие ограничения
во-первых, потомки не могут полноценно работать с базой (транзакции и все такое)
во-вторых, и это очень важно, перекладывая работу с базой на один поток, мы лишаемся всех преимуществ многопоточной работы, ведь согласитесь, 16 потоков на 16 процах писали бы в базу гораздо быстрее чем один
в-третьих, когда все потомки отработали и передали данные в родителя для записи в базу, ему нужно все эти данные записать по-очереди, и пока он пишет, он не может запустить еще потомков, ну либо тут нужно организовывать какую-то асинхронную очередь для их обработки
в общем сплошные минусы, а решение то на самом деле элементарное — сразу после форка сбрасывать коннект и соединяться заново, а родителю перед его запросами проверять — не разорван ли его коннект и пересоединяться если нужно
тупо заглушка :)
а в этом msn.gif уже был обычный JS код
т.е. делали эксперимент — создавали пустой файл, обзывали его test.php — в итоге в браузер приходил img
Из теорий почему так происходило было в основном — либо какой-то демон поселился на сервере и переписывал выдачу апача, либо контент перехватывался где-то по пути с сервера
две недели общались с хостером, так и не выяснили в чем дело, однако через 2 недели все прошло
казалось бы чего проще, но нет, ВП вообще на клиентской части весьма ущербен в возможностях