поток и читай

а как правильно передать чтобы получить файл а не поток?

Сделай как работает ,) Потом заведешь pat project и разберешься

а как правильно передать чтобы получить файл а не поток?

отправить, как минимум, элементом формы (type="file").

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

либу какую подбери

тут вопрос больше к js, а не к php

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

http://stackoverflow.com/questions/9395911/sending-a-file-as-multipart-through-xmlhttprequest

и не забудь multipart/form-data

заголовок

и вот еще пример https://gist.github.com/ebidel/2410898

а проблема у тебя была в том что не правильно формируется тело multipart реквеста и из-за $_FILES пустой

хотя в потоке ты данные видишь

http://stackoverflow.com/questions/9395911/sending-a-file-as-multipart-through-xmlhttprequest

спасибо

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

если коротко, то зачем вы юзали и как сильно вас после этого наказала жизнь?

в пхп даже не помню когда последний раз вручную деструктор делал

ну там максимум коннекты закрыть к кролику

мне нужен был враппер над курлом однажды. я в деструкторе убивал курловый хендлер

это был единственный раз

ну там максимум коннекты закрыть к кролику

а зачем руками это в деструкторе?

да ни зачем. надо же хоть раз в жизни деструктор заюзать

https://github.com/php-amqplib/RabbitMqBundle/blob/df756411351497063b79581a388589de200a496e/RabbitMq/BaseAmqp.php#L78

я думал это ты руками делал)

а какие у тебя были проблемы с gc?

никаких

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

локи?

упс, опечатался

ну, лок на ресурс

блокировки во

ну я понял

если жизненный цикл обьекта совпадает с локом, то почему бы и нет)

нууууууууу

если вдруг совпадает с реализацией gc

жизненный цикл объекта

хороший кейс)

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

да, но ты ж не знаешь когда

или ты за дедлоки переживаешь?

не знаешь когда destruct вызовут?

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

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

raii на то и придумали

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

destruct срабатывает даже при фаталах

ну и отрабатывает в ожидаемые моменты

его сложно проебать)

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

речь-то про ручное освобождение

мне правда finally вариант больше нравится

с ручным освобождением

но только если php гарантирует момент вызова деструктора

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

в gc

ну точнее, в пыхе\жсе

момент смерти не гарантируется если у тебя циклические референсы

тогда придется ждать пока он освободит его

и кстати если прибить процесс через SIGINT то нифига не сработает)

в плюсах там, все достаточно ясно, убил объект и все готово)

вроде вообще не гарантируется ни в каких случаях, как бы там написано что удаляется после того, как рефкаунт станет равным нулю, но не написано что _сразу_ после этого

вроде вообще не гарантируется ни в каких случаях, как бы там написано что удаляется после того, как рефкаунт станет равным нулю, но не написано что _сразу_ после этого

гарантируется. только нужно ждать пока соберется в хипе 10к таких обьектов

если есть островки

где такие гарантии описаны?

прям гарантии не описаны, а гц в доках описан

ERROR: S client not available

там есть такое "when the "refcount" reaches zero, the variable container is removed from memory". Больше ничего. Мне не кажется это гарантией немедленного удаления или хотя бы вызова деструктора

ты даже если сделаешь new A(); у тебя сразу же гц зачистит обьект вышел из функции - почистило и только в случае циклических зависимостей оно не сразу чистит

по реализации так, а по документации таких гарантий нет

ну или я их не нашёл

по реализации так, а по документации таких гарантий нет

там кстати так и написано, что не гарантируется порядок и момент

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

вообще 5.2 -> 5.3 должны были быть bc, и на 7 наверное

надо потестить

в 7 гц не менялся

всегда удалялось сразу как refcount станет 0

в 7 менялась только аллокация памяти

можешь форсить и юзать gc_collect_cycles()

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

а спецификацию кто-нибудь читал? Может там это написано, раз уж в доке нет

или спеку так и не приняли в итоге?

че ты так пристал к этим гарантиям? у тебя есть реальные кейсы?

реальные кейсы для чего?

hhvm ))))

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

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

hhvm ))))

у них там политика с выделением памяти на много приятнее кстати чем 7ке

я тоже на эту реализацию завязывался временами, а потом плохо спал по ночам

у них там политика с выделением памяти на много приятнее кстати чем 7ке

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

или типа того

о как. ну так поведай нас в свои кошмары)

но я может че путаю

о как. ну так поведай нас в свои кошмары)

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

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

код верифицируешь потом?

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

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

у меня на деструкторах было сделано иерархическое логирование: строился стек с информацией о бизнесовых процессах, чтобы понимать в результате какого именно процесса был сгенерён тот или иной лог. Ничего бы не случилось, если бы что-то тут пошло не так, но было бы очень неприятно