Ok, here we go:
http://dev.iworks.at/PATCHES/imap_savebody_TS.patch.txt
Regards,
--
Michael - < mike(@)php.net >
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Well, unfortunately not. It seems that net_get_buffer() in mail.c is
used as standard readfn_t which only returns NIL/T i.e. 0/1.
Okay, take two:
char buf[GETS_FETCH_SIZE];
while (size > 0) {
in toread = (size > GETS_FETCH_SIZE) ? GETS_FETCH_SIZE : size);
if (!f(stream, toread, buf)) b
I'd recommend adopting Sara's suggestion; those memset()s you have
there shouldn't be needed:
char buf[GETS_FETCH_SIZE];
while (ret > 0) {
if (!f(stream, sizeof(buf), buf))
break;
php_stream_write_string(IMAPG(gets_stream), buf);
}
return NULL;
--Wez.
On 9/26/05, Michael Wallner <[
Hi Sara Golemon, you wrote:
> Here's how I'd write this block, it assumed that f returns the number of
> bytes actually read, but according to the proto for readfn_t it *should*
> do that.
Well, unfortunately not. It seems that net_get_buffer() in mail.c is
used as standard readfn_t which only r
Looks basicly alright (with a slight disagreement on how the read loop is
implemented (below). In general you've got my vote (for what it's worth
given my lack of experience with libc-client.
unsigned long i, rest = size % GETS_FETCH_SIZE;
char *buf = emalloc(GETS_FETCH_SIZE+1);
for
Hi Sara Golemon, you wrote:
> Getting there, but you can make it work for ZTS mode. Just create a proxy
> for the gets function which is always set, then have the proxy do a
> TSRMLS_FETCH() and examine an extension global (e.g. IMAPG(gets_mode) or
> whatever) to determine whether it's in savebod
Yep, I agree with that, and some past tests of mine showed that
depending on the system, anything bigger than about 8-64K, will give
marginal performance increase (and possibly decrease depending on
memory allocation); so it's really not worth the hassle. It's also a
size which we can allocate
> > http://dev.iworks.at/PATCHES/imap_savebody.patch.txt
>
> Thanks a lot for review; the patch has been updated with your suggestions.
> Additionally the whole thing is ifdef'd out in ZTS mode as the c-client
> gets function is a global variable. I tested the function with a 17M
> message saving
I wrote:
> Currently there is no way to fetch a big message/attachment through
> ext/imap if memory_limit is enabled. I'd like to kindly ask for
> consideration of the following patch:
>
> http://dev.iworks.at/PATCHES/imap_savebody.patch.txt
Thanks a lot for review; the patch has been updated w
Use 8192 chunk size; anything bigger than that is a complete waste of memory.
--Wez.
On 9/22/05, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> Sara Golemon wrote:
> >>#define GETS_FETCH_SIZE 2048000
> >>
> >
> > That size doesn't seem a bit excessive to you? I thought the whole point of
> > dump
Sara Golemon wrote:
>>#define GETS_FETCH_SIZE 2048000
>>
>
> That size doesn't seem a bit excessive to you? I thought the whole point of
> dumping it to a file was to avoid huge memory chunks. Not to mention the
> fact that reserving 2MB of stack space makes me a little twitchy...
Indeed, 2 meg
> #define GETS_FETCH_SIZE 2048000
>
That size doesn't seem a bit excessive to you? I thought the whole point of
dumping it to a file was to avoid huge memory chunks. Not to mention the
fact that reserving 2MB of stack space makes me a little twitchy...
> /* {{{ proto bool imap_savebody(resource
12 matches
Mail list logo
