RE: remaining issues prior to 1.0?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

While researching ->ctime thoughts on list... (the entire thread might be
enlightening to review for those who want some weekend reading :)

Nearly a year ago, At 11:09 AM 6/25/2003, William A. Rowe, Jr. wrote:
>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
>
>apr_app_initialize()
>\-> 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.

And in hind site - I don't see any reason we can't implement signals on
win32 using the existing API.  The ctime issue was brought up again
and seems to be pretty important.  And mapping ACL's on HPUX/Win32
and Linux/SE seems like it's own ballgame that would 

RE: remaining issues prior to 1.0?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 02:24 AM 7/2/2004, William A. Rowe, Jr. wrote:
>[...]
>And in hind site - I don't see any reason we can't implement signals on
>win32 using the existing API.  The ctime issue was brought up again
>and seems to be pretty important.  And mapping ACL's on HPUX/Win32
>and Linux/SE seems like it's own ballgame that would 

... be it's own incremental version bump, e.g. 1.1 or whatnot.  No need
to hold up 1.0.

Sorry, full of incomplete thoughts today - it's been a long week.

Bill