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
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
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 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
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.
>>> [EMAIL PROTECTED] Friday, February 01, 2002 10:22:57 AM >>>
aaron 02/02/01 09:22:57
Modified:server scoreboard.c
Log:
Create the scoreboard (in the parent) in a global pool context, so
it
survives graceful restarts. This fixes a SEGV during graceful
restarts.
Children who attach to this scoreboard keep the same pool as before
(pchild)
since they should detach/unmap when the child process exits.
Revision ChangesPath
1.54 +21 -4 httpd-2.0/server/scoreboard.c
Index: scoreboard.c
===
RCS file: /home/cvs/httpd-2.0/server/scoreboard.c,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- scoreboard.c 30 Jan 2002 22:35:56 - 1.53
+++ scoreboard.c 1 Feb 2002 17:22:57 - 1.54
@@ -165,14 +165,27 @@
* a scoreboard shared between processes using any IPC technique,
* not just a shared memory segment
*/
-static apr_status_t open_scoreboard(apr_pool_t *p)
+static apr_status_t open_scoreboard(apr_pool_t *pconf)
{
#if APR_HAS_SHARED_MEMORY
apr_status_t rv;
char *fname = NULL;
+apr_pool_t *global_pool;
+
+/* We don't want to have to recreate the scoreboard after
+ * restarts, so we'll create a global pool and never clean it.
+ */
+rv = apr_pool_create(&global_pool, NULL);
+if (rv != APR_SUCCESS) {
+ap_log_error(APLOG_MARK, APLOG_CRIT, rv, NULL,
+ "Fatal error: unable to create global pool "
+ "for use with by the scoreboard");
+return rv;
+}
#ifndef WIN32
-rv = apr_shm_create(&ap_scoreboard_shm, scoreboard_size, fname,
p);
+rv = apr_shm_create(&ap_scoreboard_shm, scoreboard_size, fname,
+global_pool);
if ((rv != APR_SUCCESS) && (rv != APR_ENOTIMPL)) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, NULL,
"Fatal error: could not create scoreboard "
@@ -184,9 +197,13 @@
{
#endif
if (ap_scoreboard_fname) {
-fname = ap_server_root_relative(p,
ap_scoreboard_fname);
+fname = ap_server_root_relative(global_pool,
ap_scoreboard_fname);
+/* make sure the file doesn't exist before trying
+ * to create the segment. */
+apr_file_remove(fname, global_pool);
}
-rv = apr_shm_create(&ap_scoreboard_shm, scoreboard_size,
fname, p);
+rv = apr_shm_create(&ap_scoreboard_shm, scoreboard_size,
fname,
+global_pool);
if (rv != APR_SUCCESS) {
ap_log_error(APLOG_MARK, APLOG_CRIT, rv, NULL,
"Fatal error: could not open(create)
scoreboard");
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
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: 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
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
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: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 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 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
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
> > > 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. > > > > 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. > > 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
> 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
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
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. Bill > > 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
> 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...
