MS RFC 28: Redesign of LOG/DEBUG output mechanisms

[Daniel Morissette]

Tamas Szekeres wrote:
> Daniel,
> 
> As far as I can understand you propose to keep a global variable that
> will be set in msSetup() (if the environment variable is set) and
> might be modified when each mapfile is parsed. How this implementation
> would work in a multithreaded environment? For example when handling
> one request would open  /tmp/mapserver1.log while another would use
> /tmp/mapserver2.log.
> In addition I wonder how the open file handles are reusable by
> multiple threads in the various environments.
> 

I guess I didn't make that clear in the RFC, but my intention was to 
have the file handle global for a given request only, but not global 
across threads. I plan to do that by using the same mechanism that we 
already use in msGetErrorObj() (maperror.c) to have a single error stack 
per thread. Since this code seems to have worked well for a while I 
didn't expect any issue with handling the file handle the same way.


> It would be pretty useful to support the Windows OutputDebugString API
> as well. That would make the life of the Windows developers much
> easier and establish the ability to use external programs like
> SysInternals debugview to display the debug output. (I think there
> have been some  issues in the -users list in this question before) For
> using this function <windows.h> should be included which have already
> included in many places in the code.
> 

Can you provide a code sample that shows the use of OutputDebugString? 
Could it be as simple as having another special keyword for the 
MS_ERRORFILE value, for instance "windowsdebug", that sends output to 
this system? If the mechanism works in a similar way as writing to a 
file and doesn't require changing too much stuff and you can provide 
code samples that use it then I'm willing to try including this in the RFC.

Daniel
-- 
Daniel Morissette
http://www.mapgears.com/