Re: apc

val khokhlov wrote:

Hello Rasmus, Monday, February 14, 2005, 9:29:59 PM, you wrote: RL> It's the object handling stuff that is the tricky part, not managing the RL> opcodes. But yes, I can ses bcompiler and apc perhaps sharing a bit RL> more code than they do now.

         yes, surely. and it's the thing that can fix apc on php5. bcompiler

can now successfully store and restore zend structures for php5, but i don't know how to work with shared memory cache. so, sharing some function can lead to operational apc on php5. i'm going to split bcompiler.c into parts, and later one part can be used in apc, if you wish.

         and the further co-operation may lead to merging extensions (you

see, bcompiler now stores and reads bytecodes to/from php_stream, and apc does the very same thing to/from the shared memory)

         if you won't mind using bcompiler functions in apc, i'd suggest

the following changes to the my_compile_file() in apc:

    /* use this instead of just h->opened_path ! */

+ char *filename = h->opened_path ? h->opened_path : h->filename;

    /* search for the file in the cache */
    cache_entry = apc_cache_find(APCG(cache), key);
    if (cache_entry != NULL) {
-        zend_llist_add_element(&CG(open_files), h); /* XXX kludge */
+        /* add file_handle to open_file so that zend will free it */
+        if ( !(h->type == ZEND_HANDLE_FP && h->handle.fp == stdin) &&
+             !(h->type == ZEND_HANDLE_FD && h->handle.fd == STDIN_FILENO)
+           ) zend_llist_add_element(&CG(open_files), h);
-       apc_stack_push(APCG(cache_stack), cache_entry);
-       return cached_compile(TSRMLS_C);
+       /* create zend structutes from cached serialized opcodes */
+       return bcompiler_deserialize_...(cache_entry... TSRMLS_CC);
    }

    /* remember how many functions and classes existed before compilation */
    num_functions = zend_hash_num_elements(CG(function_table));
    num_classes   = zend_hash_num_elements(CG(class_table));
        /* compile the file using the default compile function */
    op_array = old_compile_file(h, type TSRMLS_CC);
    if (op_array == NULL) {
        return NULL;
    }

+ /* create serialized opcodes */ + if (bcompiler_serialize_...(&opcodes, &opcodes_len,

+                           op_array, filename, num_classes_ num_functions TSRMLS_CC)) {
+       copy_to_cache(opcodes, opcodes_len);
+       efree(opcodes);

+ } - /* cache the compiler results */ - cache_compile_results(

-       key,
-       h->opened_path,
-       apc_copy_op_array(NULL, op_array, apc_sma_malloc TSRMLS_CC),
-       apc_copy_new_functions(num_functions, apc_sma_malloc TSRMLS_CC),
-       apc_copy_new_classes(op_array, num_classes, apc_sma_malloc TSRMLS_CC));

    return op_array;

        it's not clean to me though how i can get data from the shared

memory (cache_entry->something)

        the only reason i need to return pointer to opcodes and length - as

i see, there's no way to realloc() shared memory segment, so i will create an opcodes array in the conventional memory, and then (after its size is known) it's moved to shared memory

Why would you want to serialize the opcodes and copy them around? That would slow APC to a crawl. The way it is done today the opcode array is allocated directly out of shared memory and the executor executes them directly from there. -Rasmus