Re: [PHP-DEV] Re: Re: sysvsem extention question
Chris Chabot [EMAIL PROTECTED] writes: Hey Jason, i do see your point. However, something still illudes me in my reasoning i think.. In a web envirioment, you are most likely to be in one of two situations when using semaphores. - Plain standard lock (with ability of doing resource count) - All web servers connect to a external process that handles a service (like printer) - The web processes them selves are the 'external resource' which handle the decreasing of lock-count The notes in the original source code of the php extention explained that the second+third lock were used for: - Resource count - Be able to set initial max-resource count However, when i follow this reasoning, two things come to mind - Resource count is a API provided by the sysvsem implimentation via semctl (# waiting, etc) - if you try to set the semaphore's resource count, and it fails (other process connected to it and locked it?) then wouldnt it be safe to assume that that 'other process' is another web process, which sets the same resource counters... so we end up with an good situation anyways... So if you would do a semget with IPC_CREATE + IPC_EXCL. If this succeeds, do the SETALL/SETVAL routine via semctl, if it fails on EEXISTS, do a second semget without create+excl and attach to it.. I haven't looked at the code for years, but I may have been thinking that the semaphore lives on after all the processes using it have died. So, if you change the allowed resource usage in your php code and restart the server, you want the new value to take effect and not be stuck with the old value from the last run. Donno if it would work, or how-much overhead it would add, but it sounds like it could ;-) -- Chris Jason Greene wrote: - Original Message - From: Sascha Schumann [EMAIL PROTECTED] To: Jason T.Greene [EMAIL PROTECTED] Cc: Tom May [EMAIL PROTECTED]; Chris Chabot [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, August 24, 2001 1:49 AM Subject: Re: [PHP-DEV] Re: Re: sysvsem extention question parent process right before fork. There is no parent initializer for a php module author MINIT() is called from the parent process in forking servers. The mm storage handler uses this hook to instantiate a shared memory segment and propagate the handle to all child processes. Sascha is right... Allow me to reword.. There is no way to allow a php file author the ability to execute php source during module startup of a forking web server. The module would have to allocate and initialize all semaphores before the php source is parsed. This defeats the purpose of a semaphore extension in a forking webserver environment, becuase the php source author would be limited to just the semaphors allocated by the php module. -Jason - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg Tom. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Re: sysvsem extention question
parent process right before fork. There is no parent initializer for a php module author MINIT() is called from the parent process in forking servers. The mm storage handler uses this hook to instantiate a shared memory segment and propagate the handle to all child processes. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Re: sysvsem extention question
- Original Message - From: Chris Chabot [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Cc: Sascha Schumann [EMAIL PROTECTED]; Tom May [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, August 24, 2001 11:30 AM Subject: Re: [PHP-DEV] Re: Re: sysvsem extention question Hey Jason, i do see your point. However, something still illudes me in my reasoning i think.. In a web envirioment, you are most likely to be in one of two situations when using semaphores. - Plain standard lock (with ability of doing resource count) - All web servers connect to a external process that handles a service (like printer) - The web processes them selves are the 'external resource' which handle the decreasing of lock-count The notes in the original source code of the php extention explained that the second+third lock were used for: - Resource count - Be able to set initial max-resource count However, when i follow this reasoning, two things come to mind - Resource count is a API provided by the sysvsem implimentation via semctl (# waiting, etc) - if you try to set the semaphore's resource count, and it fails (other process connected to it and locked it?) then wouldnt it be safe to assume that that 'other process' is another web process, which sets the same resource counters... so we end up with an good situation anyways... So if you would do a semget with IPC_CREATE + IPC_EXCL. If this succeeds, do the SETALL/SETVAL routine via semctl, if it fails on EEXISTS, do a second semget without create+excl and attach to it.. That should work the same as the 3 semaphore method. The thing I wonder is if the module should do this, or if this should be left up to the php programmer. I would suggest getting as close to the C API as possible, with the possibility of adding some easier to use functions. I am starting to think that any other method would be very unflexable. -Jason Donno if it would work, or how-much overhead it would add, but it sounds like it could ;-) -- Chris Jason Greene wrote: - Original Message - From: Sascha Schumann [EMAIL PROTECTED] To: Jason T.Greene [EMAIL PROTECTED] Cc: Tom May [EMAIL PROTECTED]; Chris Chabot [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, August 24, 2001 1:49 AM Subject: Re: [PHP-DEV] Re: Re: sysvsem extention question parent process right before fork. There is no parent initializer for a php module author MINIT() is called from the parent process in forking servers. The mm storage handler uses this hook to instantiate a shared memory segment and propagate the handle to all child processes. Sascha is right... Allow me to reword.. There is no way to allow a php file author the ability to execute php source during module startup of a forking web server. The module would have to allocate and initialize all semaphores before the php source is parsed. This defeats the purpose of a semaphore extension in a forking webserver environment, becuase the php source author would be limited to just the semaphors allocated by the php module. -Jason - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
