Re: [APC-DEV] Re: cvs: pecl /apc apc_main.c

On Aug 30, 2007, at 12:57 AM, Gopal V wrote:

I recall reading this a while ago as I stuck your blog on my rss feed, I think it's a great idea. My only concern immediately is how it will affect my outstanding patch for doing binary dumps to files, as I rely on these copy* functions to pull the data from the cache.

The copy* functions are going to be split into copy_in* and copy_out* and most probably all you need will be in copy_in*.

Yeah sounds good, this may do more good than harm for my code I suppose.

if there's other ways to go about this. It just may create more dependencies that we'll have to deal with. Happy to help fixup that part of the code while you make changes too though or perhaps sit on it for a while?

I've sort of been slightly concerned about putting up something like that into APC HEAD (people distributing binary php files).

The current implementation is architecture specific regarding the native type sizes so design hasn't really been focused on portability at this point. Without the ability to do binary obfuscation/encryption this doesn't seem like it would be of use to anyone for mass distribution anyways would it? I've been designing this from the standpoint of it being useful for certain in-house applications. Given, though this does pose some possible debugging difficulty.

I wouldn't mind a public patch to let me see how you do it, but pushing into mainline might be a *real* pain to maintain into the future.

The patch is currently very distinct from the rest of the codebase, but I do like to have things well tested before I propose they go in so it seems prudent to see how my use cases turn out and to see what the patch looks like. I'll be interested to see what the feedback is, and I guess we can go from there with me maintaining a patch or otherwise.

I was also thinking today that maybe we should mark --enable-pthreadmutex as not "EXPERIMENTAL" any longer. I think I have one outstanding issue with linking to look at on this, but the code itself should be pretty stable (I've been running it for a while). I'm going to take a look at spin locks here soon too to see if I can reproduce the problems Rasmus/Ilia have reported.

Yup, it'd be good to go off fcntl land for locks.

Cool. I'll switch this out then....

Let me know what you think about this, and if it's still a problem. Perhaps there is another place we could be doing this too?

Cache insert could be a place to do this (outside the locked section), rather than doing it in apc_main.c. But as of now, I'd rather not worry too much about design in that codebase - so, leave the patch in.

Right, shouldn't be terribly difficult if we need to re-factor that later. Thanks! -shire