Is MapServer Thread-safe?

[scott ellington]

Hi,

 In terms of .NET, there are really two types of thread safety
 guarantees:

 1) A completely thread safe type.  For example the Console class.
 2) A type in which static (shared) members are threadsafe, but instance
 members are not.

 Most everything in .NET is the 2nd.  C# mapscript (at least in 4.x) can
 do neither of these.  This is tedious in ASP.NET apps because you
 basically have to have a single mapObj instance and create locks around
 it.  This is what we did in MapDotNet Server.

 The concerns about writing thread-safe code really apply to the 1st
 guarantee, not the 2nd.  Yes, a completely thread-safe mapscript api
 would be inefficient and ugly, but the 2nd guarantee is a good idea.

 Scott

 On Tue, 2008-01-22 at 06:22 -0800, Dan Little wrote:
 > (steps out on a limb, presents neck to chopping block)
 >
 > After writing the below email: This probably sounds (via email) much
 > more negative and fire-starting than it is intended.  I've tried to
 > edit it to not sound that way, so please take the following statements
 > with a grain of salt, and I understand my general conclusion is,
 > "Threads are nice, processes are probably better (for some reasons),
 > and it's probably a better idea for Mapserver to work on additional
 > features and bug fixes before thread safety."
 >
 > Frankly, thread-safety-ness seems like a nice goal and all, but really
 > it can convolute the code and can create for poor performance.
 >
 > Very general:
 > http://badtux.org/home/eric/editorial/threads.php
 >
 > Good academic discussion of thread programming problems:
 > http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
 >
 > Also, I do not see thread-safety-ness serving the "mass appeal" of
 > Mapserver users and developers.  Here are a (somewhat) limited set of
 > Mapserver applications that I've found (in moderate-to-high demand
 > environments):
 >
 > 1) WFS/WMS servers, Mapserver Image serving, and Imagemap generation.
 > From my experience these are the actions that the vast majority of
 > Mapservers perform on the most regular basis.  Mapserver is
 > instantiated as a CGI script, reads the mapfile, processes the CGI
 > request and returns an appropriate result based on the request, after
 > the result is returned Mapserver ends.   You might be saying, "Yes,
 > but this creates the ever-so-scary heavyweight process." To which I
 > say the following:
 >     a) There isn't a risk for as many memory leaks with a heavyweight
 > process.  Since the heavy weight process can typically  be run in a
 > sequential fashion there is no need for complicated semaphores and
 > generally there is no need to write code that will try to grab the
 > same part of memory simultaneously.
 >     b) Heavy weight processes can use more memory, yes, but given the
 > Mapserver binary's relative size, even with every option under-the-sun
 > compiled into the binary, a system with 1Gb of RAM and a Pentium IV
 > can still adequately serve nearly 300 users without a significant
 > bottle neck (assuming all other parts of the system are adequate for
 > those demands, e.g., the network to which the machine is connected).
 > The baseless claim is made from the experiences we had at the City of
 > Saint Paul serving nearly that many users off of a relatively pathetic
 > single-CPU mid-range Dell-server.
 >     c) "The operating system is better at process management than you
 > are."  This is something I've head to learn the HARD WAY!   It's also
 > something I've spent a lot of time coding that I learned I should not
 > have spent coding because entire teams of developers had already done
 > a much better job than I was doing.  Having to consider resource
 > management a top actual application development and trying to do any
 > form of optimization can leave any developer chasing their tail.   And
 > even once that code is "perfected" there is still a fight with the
 > operating system over threads.   Thread clean-up is a very difficult
 > thing for the operating system to perform (especially Windows, which
 > really only "emulates" POSIX thread management).  The OS has no
 > deterministic way of knowing when the code is done with the thread and
 > most will keep the thread around for a while after it thinks it's done
 > (even if the code tells the OS to free the thread) because it doesn't
 > want to upset the execution of the code.   When a process calls exits
 > or reaches the end of the code block the OS can rightly say those
 > pages of memory can be freed.
 >     d) "But the data will be unloaded from memory and my files are
 > BIG."  Not true on any modern operating system.   Operating systems
 > manage disk cache for a reason.  Every modern OS, all the UNIX/Linux
 > derivatives and NT4+, implements a very good method for caching
 > frequently used files.  Even if the file is large, it will be kept in
 > memory if it is being called frequently enough.
 >     In conclusion, these users would not see a major benefit from
 > people slaving hours away at thread-safety, when in fact, greater
 > optimization would "help" them the most.
 >
 > 2) Mapscripters!  Mapscript is fantastic, it is a very well documented
 > API into Mapserver, which is a coalescing of a number of very useful
 > libraries.  I'm quite sure a lot of folks here have spent some time
 > working with Mapscript and a number of them in high-demand
 > environments.  I under stand the .Net family of languages break this
 > rule, but most of the "Mapscript languages" really do not require
 > thread safety to run efficiently or to handle a great number of users.
 > Arguably most of the scripting languages in a CGI environment perform
 > the following steps:  load the interpreter (php/python/perl/etc.), the
 > interpreter parses the script, loads/links the appropriate
 > modules/libraries, executes the code, cleans up the processes.  The
 > vast majority of these are done using a "heavy weight" process
 > (fork()'d!).
 >
 >
 > ----- Original Message ----
 > From: Umberto Nicoletti <umberto.nicoletti at GMAIL.COM>
 > To: MAPSERVER-DEV at LISTS.UMN.EDU
 > Sent: Tuesday, January 22, 2008 7:34:56 AM
 > Subject: Re: [UMN_MAPSERVER-DEV] Is MapServer Thread-safe?
 >
 > >
 > > We're tending to summarize these in the thread safety faq. However
 > > it's slightly outdated and I'm not totally sure about the actual
 > state
 > > of the components enumerated there.
 > >
 >
 > I update that FAQ entry whenever I find out that a new component has
 > been made thread safe (and I have some spare time ;-)).
 > Anyway, I think it pretty accurately describes the current state,
 > except maybe for the new and not yet released SQLServer 2008 plugin.
 >
 > Umberto
 >
 >
 >
 >
 >
 > ______________________________________________________________________
 > Never miss a thing. Make Yahoo your homepage.