From: Felix R. <fe...@ra...> - 2008-08-27 22:00:22
|
Tom, I am a little surprised by some of your statements: - Virtual hardware does not accurately test for OS specific issues because of the virtual hardware drivers. I didn't see any differences. Can you be more specific. I am running Suse under VMWare on Vista x86; and Fedora and Vista (both 64-bit) on Win2008 64-bit server under Hyper-V - PHP 5.0 or later We don't want to be cavalier about this recommendation. Many users are running Gallery in ISP environment where they don't have too much choice. Moreover, Gallery 2.3 requires 4.x (I think 4.3 although I am not sure), and 2.4 will require 5.2. Requiring 5.0 isn't persuasive (sounds like "out of the blue" requirements). - Mysql 5.0 or later Same as above. Are you expereinceing any problems with 4.1 series... or for that matter, 4.0? I don't think we are using any 5.0-specific features. PHP thread-safe. Unlike Jessee, I slept through my OS class... but it never prevented me from expressing my 2 cents before. I think there are different considerations for different servers (Apache, IIS), Operating systems (Linux / Windows), and modes (CGI, module/isapi, FastCGI on IIS7) - therefore your question "is PHP 5.X and later considered "thread safe" for the php modules Gallery requires" seems very ambiguous. Do you feel that Gallery has some unique requirements that go beyond what is specified on Apache / Microsoft / PHP sites? On Wed, 27 Aug 2008 12:34:56 -0700, Tom wrote: Hi all, A couple things to think about and a question. ONE: I noticed it takes over 200 meg of PHP ram to get through these tests. (169,922,480 under debian but it won't run in less than 220 or so) Is this normal and/or intentional? PHP fails with no error message when it's out of ram? I've been working on setup guides. I'm currently recommending: *Not to use VMWare or other any ohter Virtual machine for testing on a daily use desktop box, especially under Vista. Why? Virtual hardware does not accurately test for OS specific issues because of the virtual hardware drivers. *Minimum hardware PIII Coppermine or AMD K6 or older Athlon (1400 mhz+) with 384 meg RAM, 20gig HD *Apache 2.0 or later i386 mpm prefork *PHP 5.0 or later *Mysql 5.0 or later TWO: This is a somewhat controversial issue and an "off the beaten path" comment/question on php & thread safety. I haven't kept up with php development but I assume a thread safe version is, or will be available soon for both 32 & 64 bit operating environments. I hope so, multi threading is potentially the best way to improve performance. We've been in a multitasking, multiuser computing environment since the i486 heralded a few hardware context (stack switching) additions and we began running Windows 3.1. When Fidonet and the 2400 bps BBS were the only kings to be found on the end of a modem. My understanding is this, in case anyone wishes to join a "thread safe" discussion: Being "thread safe" generally means an application is built as a group of small library modules that can be, but aren't necessarily, executed via a software interrupt. I've found this to be a good test of thread safety. In most cases the modules are grouped such that routines used the most are in a main library / load module and other less used functions are loaded as needed with a lower code swap priority that maintains their address space linkage but allows them to be swapped sooner than core modules. For example, look at how much swap space MS Vista uses just after booting. Many of it's less used but already "linked" modules are swapped immediately because, in most cases, it's faster to grab a block of linked code from swap than load it from disk and link it to ram on the fly. Thread safe implies these modules have "re-entrant" capable code. Re entrant code requires either the library function itself (really old school but probably still done) or some kind of OS or hardware based "thread / memory manager", issue a unique execution ID (called "partial context addressing" for data & stack offsets) to each and every executable occurrence of a "thread safe" module/subroutine. Additionally the module code "should" save it's state between the calling "int" and "iret" or it's initial entry point and it's final exit so it can determine if it's been "tampered with" between calls (sp > X?, is my execution lock set?, is there a hardware based checksum I can test?) and to help prevent obvious code failure should a second copy of the code be called with the same ds/ss pointers, or to check for an errant program that may have run over the top of your segments. Hey, even hardware context managers get messed up sometimes and windows... Let's just say that Bill is sometimes in the wrong place. It's like the three bears: What are YOU doing in MY bed? Normal processor context switching mechanisms will save and restore any "context relevant" registers and segment pointers required for a block of code to execute as a thread so the code block need not worry about it's stack, it's data segment, it's code segment or it's "temporarily commandeered" processor registers when it's "interrupted" by the task switcher. Additionally a block of code can be executed with various "interrupt prevention" or "priority modification" mechanisms like countdown clocks, software loop counters, "undesirable code name" blacklist priority drops etc. to force it's priority higher or lower in relation to other tasks. Most multi tasking operating systems make use of underlying hardware context switching mechanisms to significantly increase performance by reducing the need for full software based thread management (managing memory address space & assigning that all important new thread ID and it's partial context pointers). Such routines are absolutely necessary for things like NIC drivers and the like since we don't know when they will require servicing. So, why is PHP having so much trouble with a "thread safe" version that will execute appropriately with Apache's Worker thread version? Is this a "performance" issue, an OS specific task execution issue, a RAM usage issue, a lack of talented programming support or an unforeseen political or licensing issue? Realizing that many php modules are coded by people other than the php development team, is PHP 5.X and later considered "thread safe" for the php modules Gallery requires? Is it rational to try to setup & test a worker thread version of Apache for Gallery2? -Tom |