Re: cvs commit: httpd-2.0/server scoreboard.c
[EMAIL PROTECTED] wrote: minfrin 2003/04/05 11:48:02 Modified:server Tag: APACHE_2_0_BRANCH scoreboard.c Log: - Clarify an error message to be more useful Graham, Things need to be in 2.1-dev first, or at least within a very short time of committing to 2.0.x-dev. If you'd tried to put this in 2.1-dev first, you'd have noticed that Martin coded the same change with slightly different wording 12 days ago. Can you pick whichever message flavor you like and get them in synch pretty please? Thanks, Jeff
Re: cvs commit: httpd-2.0/server scoreboard.c
On Fri, Feb 01, 2002 at 11:00:11AM -0700, Brad Nicholes wrote: Why is the platform #ifdef WIN32 being included in an HTTPD source file? I thought the whole idea was to keep platform specific code out of the general HTTPD source and put it in APR. It is admittedly lame, but it is only temporary. I have a fix in the works that makes this completely platform neutral, but I'm waiting to test and apply until after our current tag/release cycle (and until I have more time). -aaron
Re: cvs commit: httpd-2.0/server scoreboard.c
Just checking. Thanks, [EMAIL PROTECTED] Friday, February 01, 2002 11:26:30 AM From: Brad Nicholes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 01, 2002 12:00 PM Subject: Re: cvs commit: httpd-2.0/server scoreboard.c Why is the platform #ifdef WIN32 being included in an HTTPD source file? I thought the whole idea was to keep platform specific code out of the general HTTPD source and put it in APR. Brad, the Unix code is wrong, but it clobbered Win32 (which could not create a NULL sharemem at that moment.) Now Win32 supports unnamed scoreboards, so that code _could_ go away; however... Aaron is working on reverting to use-named-scoreboard if a name is given in the conf file, or anon (unnamed) shm otherwise. When that patch goes into the Unix MPM's - this code may all be reverted to the Win32 path here. Yes - platforms do NOT belong in the httpd sources. For a temporary and quick fix, however, this is prefereable to having entirely broken platforms :) Bill
Re: cvs commit: httpd-2.0/server scoreboard.c
On Thu, Jan 24, 2002 at 12:18:51PM -0600, William Rowe wrote: From: Aaron Bannert [EMAIL PROTECTED] Sent: Thursday, January 24, 2002 12:09 PM I had thought that on platforms that supported it, we would prefer the anonymous shared memory (as we were using before) to a name-based solution, for whatever reason (performance and/or security perhaps). I have no empirical evidence claiming either to be superior, I just wanted to leave the underlying scoreboard mechanism as close as possible to what it was before the recent shmem changes. How about this: - if the user specifies a ScoreboardFile then we use name-based memory with that file, and failures are absolute. - if none is specified, we get to chose -- right now i see this as - platforms with fork try anonymous* then fall back to name-based - other platforms do name-based (for name-based we have to come up with a name like what we have now. If it happens to be on an NFS partition, then it may fail, but we'll have made notice of this in the docs and the config comments.) Actually, win32 will do anonymous in just a few minutes more, if no file backing name is given. Please proceed with a patch to correct, as you've described. I'm planning on making these changes shortly, but what is the group consensus on what the default ScoreboardFile should be? I'm thinking we should remove it from the default httpd.conf, and only leave a comment or leave it up to the docs to explain the behavior. OTOH we may still need it for win32. In any case, I am in favor of defaulting to anonymous shared memory on Unix. -aaron
Re: cvs commit: httpd-2.0/server scoreboard.c
From: Aaron Bannert [EMAIL PROTECTED] Sent: Wednesday, January 30, 2002 10:08 AM On Thu, Jan 24, 2002 at 12:18:51PM -0600, William Rowe wrote: Sent: Thursday, January 24, 2002 12:09 PM I had thought that on platforms that supported it, we would prefer the anonymous shared memory (as we were using before) to a name-based solution, for whatever reason (performance and/or security perhaps). I have no empirical evidence claiming either to be superior, I just wanted to leave the underlying scoreboard mechanism as close as possible to what it was before the recent shmem changes. How about this: - if the user specifies a ScoreboardFile then we use name-based memory with that file, and failures are absolute. - if none is specified, we get to chose -- right now i see this as - platforms with fork try anonymous* then fall back to name-based - other platforms do name-based (for name-based we have to come up with a name like what we have now. If it happens to be on an NFS partition, then it may fail, but we'll have made notice of this in the docs and the config comments.) Actually, win32 will do anonymous in just a few minutes more, if no file backing name is given. It now does, of course. Please proceed with a patch to correct, as you've described. I'm planning on making these changes shortly, but what is the group consensus on what the default ScoreboardFile should be? I'm thinking we should remove it from the default httpd.conf, and only leave a comment or leave it up to the docs to explain the behavior. OTOH we may still need it for win32. In any case, I am in favor of defaulting to anonymous shared memory on Unix. Just like the 1.3 httpd config of the LockFile, if we leave it commented out, and let the user uncomment it, with some notes to say 'if your platform requires this directive, you will recieve the error . Otherwise, enable only if another program must have access to the scoreboard.' Make sense? Bill
Re: cvs commit: httpd-2.0/server scoreboard.c
From: Bill Stoddard [EMAIL PROTECTED] Sent: Thursday, January 24, 2002 8:57 AM Bill, This triggered a question... I have not followed the discussion on this thread closely, but are you requiring the ScoreBoardFile directive on Windows to name the shmem? I hope not. At this moment, yes, otherwise it defaults to the parent/private, child/private model. Do you want that changed, effective now, to always have a shared score? It must become a shared score before we can proceed to multi-process, but we aren't quite there, yet. Bill
Re: cvs commit: httpd-2.0/server scoreboard.c
From: Bill Stoddard [EMAIL PROTECTED] Sent: Thursday, January 24, 2002 8:57 AM Bill, This triggered a question... I have not followed the discussion on this thread closely, but are you requiring the ScoreBoardFile directive on Windows to name the shmem? I hope not. At this moment, yes, otherwise it defaults to the parent/private, child/private model. Do you want that changed, effective now, to always have a shared score? It must become a shared score before we can proceed to multi-process, but we aren't quite there, yet. Bill In the cases where we want/need a shared scoreboard, I would prefer for the parent to derive a safe name and tell the child the name. I see no goodness in complicating the config with a directive that does not provide a distinct benefit to the user. IMHO, the name of the shared segment (and the process for deriving the name) is best kept under the covers. Bill
Re: cvs commit: httpd-2.0/server scoreboard.c
Bill, This triggered a question... I have not followed the discussion on this thread closely, but are you requiring the ScoreBoardFile directive on Windows to name the shmem? I hope not. At this moment, yes, otherwise it defaults to the parent/private, child/private model. Do you want that changed, effective now, to always have a shared score? It must become a shared score before we can proceed to multi-process, but we aren't quite there, yet. In the cases where we want/need a shared scoreboard, I would prefer for the parent to derive a safe name and tell the child the name. I see no goodness in complicating the config with a directive that does not provide a distinct benefit to the user. IMHO, the name of the shared segment (and the process for deriving the name) is best kept under the covers. You didn't answer my question :) First off, to your response, IF the user specifies a filename, I strongly believe we use that name. If the user leaves ScoreboardFile unspecified, then we do what _we_ feel is best. I believe this applies to Win32 and Unix, as well, and made that comment to Aaron's patch. Now, if the user doesn't specify a ScoreboardFile _today_, then we leave well enough alone, and the parent and child don't share a scoreboard. That's fine, until we go to multiple processes. Unless we want to begin using the shared score today, always. As far as our inventing that shared resource [If the user assign the file backing with ScoreboardFile]; I have a philosophy. You create the child detached. We dup the handle to the shared score to the child's process, and pass it down the pipe. We need the apr_os_shm_get/put to make this happen, but that's a trivial patch. My Q to you - share a scoreboard, starting today, always? Or only if we actually care? [3rd party module/app or when we get to multi-proc.] Bill
Re: cvs commit: httpd-2.0/server scoreboard.c
Bill, This triggered a question... I have not followed the discussion on this thread closely, but are you requiring the ScoreBoardFile directive on Windows to name the shmem? I hope not. At this moment, yes, otherwise it defaults to the parent/private, child/private model. Do you want that changed, effective now, to always have a shared score? It must become a shared score before we can proceed to multi-process, but we aren't quite there, yet. In the cases where we want/need a shared scoreboard, I would prefer for the parent to derive a safe name and tell the child the name. I see no goodness in complicating the config with a directive that does not provide a distinct benefit to the user. IMHO, the name of the shared segment (and the process for deriving the name) is best kept under the covers. You didn't answer my question :) You answered my question with a question :-) Seriously... I'm a bit of a performance nut. If the shared scoreboard does not impose a performance hit, then may as well begin using it (assuming it even works of course:-). We clearly need to introduce multiple child processes under Windows and the shared score is a prereq. First off, to your response, IF the user specifies a filename, I strongly believe we use that name. +1 If the user leaves ScoreboardFile unspecified, then we do what _we_ feel is best. I believe this applies to Win32 and Unix, as well, and made that comment to Aaron's patch. +1 Now, if the user doesn't specify a ScoreboardFile _today_, then we leave well enough alone, and the parent and child don't share a scoreboard. That's fine, until we go to multiple processes. Unless we want to begin using the shared score today, always. As far as our inventing that shared resource [If the user assign the file backing with ScoreboardFile]; I have a philosophy. You create the child detached. We dup the handle to the shared score to the child's process, and pass it down the pipe. We need the apr_os_shm_get/put to make this happen, but that's a trivial patch. My Q to you - share a scoreboard, starting today, always? Or only if we actually care? [3rd party module/app or when we get to multi-proc.] I was not able to parse all of the last two paragraphs... Any downsides to a shared score today? If not, then lets begin using a shared score now. Bill Bill
RE: cvs commit: httpd-2.0/server scoreboard.c
Bill, This triggered a question... I have not followed the discussion on this thread closely, but are you requiring the ScoreBoardFile directive on Windows to name the shmem? I hope not. At this moment, yes, otherwise it defaults to the parent/private, child/private model. Do you want that changed, effective now, to always have a shared score? It must become a shared score before we can proceed to multi-process, but we aren't quite there, yet. Bill In the cases where we want/need a shared scoreboard, I would prefer for the parent to derive a safe name and tell the child the name. I see no goodness in complicating the config with a directive that does not provide a distinct benefit to the user. IMHO, the name of the shared segment (and the process for deriving the name) is best kept under the covers. Just to be clear, that is not what Unix does now. If you need a file backing the scoreboard, we make you add one. Ryan
Re: cvs commit: httpd-2.0/server scoreboard.c
Bill, This triggered a question... I have not followed the discussion on this thread closely, but are you requiring the ScoreBoardFile directive on Windows to name the shmem? I hope not. At this moment, yes, otherwise it defaults to the parent/private, child/private model. Do you want that changed, effective now, to always have a shared score? It must become a shared score before we can proceed to multi-process, but we aren't quite there, yet. Bill In the cases where we want/need a shared scoreboard, I would prefer for the parent to derive a safe name and tell the child the name. I see no goodness in complicating the config with a directive that does not provide a distinct benefit to the user. IMHO, the name of the shared segment (and the process for deriving the name) is best kept under the covers. Just to be clear, that is not what Unix does now. If you need a file backing the scoreboard, we make you add one. Ryan The issue is not whether we need a file backing the scoreboard. On Unix, you make the scoreboard use a file when the OS does not support shared memory. On Unix systems that support shared memory, we create the shared memory in the parent, fork and the child processes automagically have access to that shared memory. Windows does not support fork, so the shared memory created in the parent needs to become visible to the child processes some how. One way to make that shared memory visible is to give it a name that the parent and child processes know. My question/concern was how to communicate that name. I do NOT want to REQUIRE an admin to explicitly name the shared memory segment with a config directive. If he wants to, fine but it should not be a requirement, just as it is not a requirement on Unix today. If my explanation was not sufficient, talk to Bill Rowe, cause I think we see eye-to-eye on this based on our last exchange. That will save me typing and list subscribers reading :-) Bill
RE: cvs commit: httpd-2.0/server scoreboard.c
On Thu, Jan 24, 2002 at 11:23:39AM -0500, Bill Stoddard wrote: The issue is not whether we need a file backing the scoreboard. On Unix, you make the scoreboard use a file when the OS does not support shared memory. I think Aaron pointed out in a recent exchange with a FreeBSD user that we don't support any OS without shared memory (FreeBSD disables shmem in a jail). IIRC, file-backed scoreboards are no longer supported in 2.0 (i.e. no use of shmem at all). Some OSes require a path to setup the scoreboard via shmem. FWIW, this seems identical to your issue in Win32. (I could be wrong, but that is my interpretation.) -- justin I think you are 100% spot on, which was my original point. Unix requires a filename to be setup for most shared memory implementations. Windows should work exactly the same way, right down to supporting the ScoreBoardFile directive. Ryan
Re: cvs commit: httpd-2.0/server scoreboard.c
On Thu, Jan 24, 2002 at 10:27:12AM -0500, Bill Stoddard wrote: In the cases where we want/need a shared scoreboard, I would prefer for the parent to derive a safe name and tell the child the name. I see no goodness in complicating the config with a directive that does not provide a distinct benefit to the user. IMHO, the name of the shared segment (and the process for deriving the name) is best kept under the covers. Deriving a filename for the scoreboard may be more difficult than it sounds -- we don't want the file to reside on an NFS partition. -aaron
Re: cvs commit: httpd-2.0/server scoreboard.c
On Thu, Jan 24, 2002 at 08:29:01AM -0800, Justin Erenkrantz wrote: On Thu, Jan 24, 2002 at 11:23:39AM -0500, Bill Stoddard wrote: The issue is not whether we need a file backing the scoreboard. On Unix, you make the scoreboard use a file when the OS does not support shared memory. I think Aaron pointed out in a recent exchange with a FreeBSD user that we don't support any OS without shared memory (FreeBSD disables shmem in a jail). IIRC, file-backed scoreboards are no longer supported in 2.0 (i.e. no use of shmem at all). Some OSes require a path to setup the scoreboard via shmem. FWIW, this seems identical to your issue in Win32. (I could be wrong, but that is my interpretation.) -- justin Actually, one of the name-based shared memory types on Unix is an mmap()ed file. If that is how we were doing file-backed shared memory before then it's still in there. The bigger point here is that we don't make a distinction between file-backed and non-file-backed shared memory anymore. The only distinction we have is anonymous and name-based. All name-based shmem types rely on a file in the filesystem, either to rendezvous two unrelated processes or to back (store) the actual shared data. I had thought that on platforms that supported it, we would prefer the anonymous shared memory (as we were using before) to a name-based solution, for whatever reason (performance and/or security perhaps). I have no empirical evidence claiming either to be superior, I just wanted to leave the underlying scoreboard mechanism as close as possible to what it was before the recent shmem changes. How about this: - if the user specifies a ScoreboardFile then we use name-based memory with that file, and failures are absolute. - if none is specified, we get to chose -- right now i see this as - platforms with fork try anonymous* then fall back to name-based - other platforms do name-based (for name-based we have to come up with a name like what we have now. If it happens to be on an NFS partition, then it may fail, but we'll have made notice of this in the docs and the config comments.) (*anonymous shmem should not reattach in the child) -aaron
Re: cvs commit: httpd-2.0/server scoreboard.c
On Thu, Jan 24, 2002 at 10:09:50AM -0800, Aaron Bannert wrote: How about this: - if the user specifies a ScoreboardFile then we use name-based memory with that file, and failures are absolute. - if none is specified, we get to chose -- right now i see this as - platforms with fork try anonymous* then fall back to name-based - other platforms do name-based (for name-based we have to come up with a name like what we have now. If it happens to be on an NFS partition, then it may fail, but we'll have made notice of this in the docs and the config comments.) (*anonymous shmem should not reattach in the child) Oh yeah, and this is how it is now, except for the first point (we don't let the ScoreboardFile override our preference, but we should) and the minor bug that apache needs to remove the scoreboard file before trying the shmem. -aaron
Re: cvs commit: httpd-2.0/server scoreboard.c
From: Aaron Bannert [EMAIL PROTECTED] Sent: Thursday, January 24, 2002 12:09 PM I had thought that on platforms that supported it, we would prefer the anonymous shared memory (as we were using before) to a name-based solution, for whatever reason (performance and/or security perhaps). I have no empirical evidence claiming either to be superior, I just wanted to leave the underlying scoreboard mechanism as close as possible to what it was before the recent shmem changes. How about this: - if the user specifies a ScoreboardFile then we use name-based memory with that file, and failures are absolute. - if none is specified, we get to chose -- right now i see this as - platforms with fork try anonymous* then fall back to name-based - other platforms do name-based (for name-based we have to come up with a name like what we have now. If it happens to be on an NFS partition, then it may fail, but we'll have made notice of this in the docs and the config comments.) Actually, win32 will do anonymous in just a few minutes more, if no file backing name is given. Please proceed with a patch to correct, as you've described. Bill
Re: cvs commit: httpd-2.0/server scoreboard.c
aaron 02/01/22 22:51:18 Modified:server scoreboard.c Log: Although this patch is technically correct, I'm not happy with the way it gets things done. OTOH, it is a simple enough change to get things working correctly for now. I will come up with the right way to do this in the next couple days. This patch re-enables the use of anonymous shared memory in the scoreboard on platforms that have it. Well chicken 'n eggs... one way or another this patch broke win32. Now I'm researching what/how to get both anon and file backed win32 shm.c working. Fixing that bug makes the win32 startup failures disappear. But this does break a simple idea behind the win32 shmem. I had intended to create the scoreboard as shared, only if named. The create anon _does_ create anon memory on win32, ENOTIMPL is not an acceptable solution. The issue is that we are a forked platform. Therefore, you can't make the assumption that anon is preferred. Maybe you prefer it, but we on win32 sure don't, and other platforms may agree for other reasons. So I suggest we back out the patch, and instead, use this logic; rather than always creating the DEFAULT scoreboard name, leave it Null on all platforms that support anon memory. If the user specifies a filename, use it. If the user omits the ScoreboardName, then they receive anon memory. And if APR lacks anon support, keep using a default scoreboard name on the platform. Does this make any sense? It would allow 3rd party apps to share and access the scoreboard by name, when the user configures it, and regardless of our default preference for that platform. Bill
Re: cvs commit: httpd-2.0/server scoreboard.c
[EMAIL PROTECTED] writes: trawick 01/12/24 13:00:18 Modified:server scoreboard.c Log: fix a horrible bug which caused scoreboard initialation to always exit my horrible bug... not much of a Christmas present... Sorry! Maybe everybody else had enough sense not to play on Christmas Eve so nobody was affected (hoping :) ). -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
