apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: remaining issues prior to 1.0?
Date Wed, 25 Jun 2003 16:09:46 GMT
At 03:27 AM 6/25/2003, Marc M. Adkins wrote:
>> * emulating the daemon/services foo within the Win32 port... but call it
>>   a 'nice to have' ... I will try to dedicate cycles to this over
>> the summer.
>>   It's not exactly a showstopper.
>Can you expand on this?  Are you talking about the usual "Windows doesn't
>fork" problem, emulating Windows services on Linux, getting process data
>(memory size, CPU %, etc.) or something else entirely?
>Just curious.

although I would *really* like to deal with fork() ... it isn't practical (topic
for another thread).

I was restricting my focus to mapping Service 'Events' -> Unix Signals,
such as stop, start, shutdown, and marking Apache as 'already daemonized'
when you start as a service.

My only headache - I spent some time trying to find how we can safely
assert that this WinNT/2K/XP/2003 process is running within the SCM
(NT kernel service control manager).  The short answer so far; it isn't
very pretty.  If we knew that, we would have APR react and start a service
control thread, and then enter the NT event processing loop.

On the Win9x side, implement daemonize_process to dismiss the window
and mark the process as a 'psuedo-service'.  Again, the hidden window we
create to track Apache shutting down would trigger our 'unix' signals.

so it looks on NT as

\-> Running as service?
    \-> Spin up service monitor and nt eventlog capture thread for stderr
        \-> In service monitor thread, call into the SCM to be called back.
            \-> Fix the argv[] based on the ServiceStart args.

and then react to service control signals to the monitor thread based on
our apr_signals() API.

The only other two big thorns left in APR?  File Create time isn't the same
as the inode modified ctime.  And we don't have an API to map ACL 
management between implementations, nor a way for Win32 to handle
setuid().  In Win32's case, we need the account 'password' to deal with
a setuid() request.  The first is a real bug to fix, the second is perhaps
beyond the scope of releasing 1.0.


View raw message