htdigest woes

[Paul Sutton <pa...@ukweb.com>]

htdigest does not compile. It includes core/conf.h (from md5c.c) which
maps signal() onto ap_signal(). This function is defined in http_main.c,
which is not part of htdigest. Probably the simplest solution is to not
bother with sigaction handling in htdigest since its not a critical
application. The patch below prevents the mapping of signal() onto
ap_signal() (and hence the new signal() in http_main.c).

The alternative is to abstract out the new signal from http_main.c to and
allow all support apps to have access to it. 

//pcs

Index: Makefile.tmpl
===================================================================
RCS file: /export/home/cvs/apachen/src/support/Makefile.tmpl,v
retrieving revision 1.4
diff -u -r1.4 Makefile.tmpl
--- Makefile.tmpl	1997/07/20 23:44:49	1.4
+++ Makefile.tmpl	1997/08/15 08:43:24
@@ -19,7 +19,7 @@
 	$(CC) $(CFLAGS) htpasswd.c -o htpasswd $(LIBS)
 
 htdigest: htdigest.c
-	$(CC) $(CFLAGS) htdigest.c -o htdigest $(LIBS)
+	$(CC) $(CFLAGS) -DNO_USE_SIGACTION htdigest.c -o htdigest $(LIBS)
 
 httpd_monitor: httpd_monitor.c
 	$(CC) $(INCLUDES) $(CFLAGS) httpd_monitor.c -o httpd_monitor

Re: htdigest woes

[Dean Gaudet <dg...@arctic.org>]

Yeah we can leave http_main until after 1.3 ... I've been thinking about
the various abstractions in it and how to break it up.  In about a month
I'll probably have a doc together. 

Dean

On Fri, 15 Aug 1997, Paul Sutton wrote:

> On Fri, 15 Aug 1997, Dean Gaudet wrote:
> > And rip apart http_main.c into a WIN32 version and a unix version.  I'm
> > getting soooo lost in it lately.
> 
> Yeah, tell me something I don't know.
> 
> The difficulty with ripping out Win32 stuff is that there is no distintion
> (at the moment) between stuff that is pure win32 (e.g. the spawning of
> worker_main() processes) vs. stuff that is related to multithread per se
> (e.g. the work that worker_main() does). It would be a mistake to abstract
> out MT stuff as part of a Win32 abstractions. Really we need to abstract
> out the MT stuff separately, and provide an abstract layer for MT
> primatives (pthread_*() calls, etc) instead of win32's CreateMutex() and
> friends. Then the MT code can be used for Unix as well at some point in
> the future.
> 
> All of which is a major restructuring, so I think should be left to after
> 1.3. What I want to abstract before 1.3 is everything else that is OS
> dependent (path mappings, opening files, symlinks, child process creation) 
> etc. 
> 
> //pcs
> 
> 
> 

Re: htdigest woes

[Paul Sutton <pa...@ukweb.com>]

On Fri, 15 Aug 1997, Dean Gaudet wrote:
> And rip apart http_main.c into a WIN32 version and a unix version.  I'm
> getting soooo lost in it lately.

Yeah, tell me something I don't know.

The difficulty with ripping out Win32 stuff is that there is no distintion
(at the moment) between stuff that is pure win32 (e.g. the spawning of
worker_main() processes) vs. stuff that is related to multithread per se
(e.g. the work that worker_main() does). It would be a mistake to abstract
out MT stuff as part of a Win32 abstractions. Really we need to abstract
out the MT stuff separately, and provide an abstract layer for MT
primatives (pthread_*() calls, etc) instead of win32's CreateMutex() and
friends. Then the MT code can be used for Unix as well at some point in
the future.

All of which is a major restructuring, so I think should be left to after
1.3. What I want to abstract before 1.3 is everything else that is OS
dependent (path mappings, opening files, symlinks, child process creation) 
etc. 

//pcs

Re: htdigest woes

[Dean Gaudet <dg...@arctic.org>]

And rip apart http_main.c into a WIN32 version and a unix version.  I'm
getting soooo lost in it lately.

Dean

On Fri, 15 Aug 1997, Paul Sutton wrote:

> On Fri, 15 Aug 1997, Dean Gaudet wrote:
> > On Fri, 15 Aug 1997, Paul Sutton wrote:
> > > The alternative is to abstract out the new signal from http_main.c to and
> > > allow all support apps to have access to it. 
> > 
> > I thought this was one of the goals of the reorg.
> 
> Yeah, but do we do it before 1.3 goes into beta? I think we ought to,
> but there was no reply to a recent message when I asked this question (and
> showed an example of how the abstraction could work).
> 
> There is also the issue that we have abstracted the major platforms
> (Win32, OS/2, Unix) into src/os/*, but somewhat inconsistently the
> variations of these platforms are still defined within src/core (i.e. in
> src/core/conf.h). It might make sense to move src/core/conf to
> os/unix/os.h (and move the the OS/2 and Win32 bits from conf.h to
> os/{win32,emx}/os.h). *Then* we can start throwing the new #defines into
> the relevant os.h, and where necessary abstracting functions in os/*/os.c
> such as ap_is_path_absolute(), etc.
> 
> //pcs
> 
> 
> 

Re: htdigest woes

[Paul Sutton <pa...@ukweb.com>]

On Fri, 15 Aug 1997, Dean Gaudet wrote:
> On Fri, 15 Aug 1997, Paul Sutton wrote:
> > The alternative is to abstract out the new signal from http_main.c to and
> > allow all support apps to have access to it. 
> 
> I thought this was one of the goals of the reorg.

Yeah, but do we do it before 1.3 goes into beta? I think we ought to,
but there was no reply to a recent message when I asked this question (and
showed an example of how the abstraction could work).

There is also the issue that we have abstracted the major platforms
(Win32, OS/2, Unix) into src/os/*, but somewhat inconsistently the
variations of these platforms are still defined within src/core (i.e. in
src/core/conf.h). It might make sense to move src/core/conf to
os/unix/os.h (and move the the OS/2 and Win32 bits from conf.h to
os/{win32,emx}/os.h). *Then* we can start throwing the new #defines into
the relevant os.h, and where necessary abstracting functions in os/*/os.c
such as ap_is_path_absolute(), etc.

//pcs

Re: htdigest woes

[Dean Gaudet <dg...@arctic.org>]

On Fri, 15 Aug 1997, Paul Sutton wrote:

> The alternative is to abstract out the new signal from http_main.c to and
> allow all support apps to have access to it. 

I thought this was one of the goals of the reorg.

Dean