That's the cool thing about opensource. If your paying customers are demanding new features, you can improve the code base yourself, or fund someone to add the functionality for you.
-----Original Message----- From: UMN MapServer Users List [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Dege Sent: Friday, June 23, 2006 4:06 PM To: [email protected] Subject: Re: [UMN_MAPSERVER-USERS] Thread-safety in mapscript_csharp.dll? > -----Original Message----- > From: Tamas Szekeres [mailto:[EMAIL PROTECTED] > Sent: Friday, June 23, 2006 3:32 PM > To: Jeff Dege > Cc: [email protected] > Subject: Re: [UMN_MAPSERVER-USERS] Thread-safety in > mapscript_csharp.dll? > > Hi, > > MapServer was originally created to use in a single threaded > application model, mapserv.exe is a single threaded CGI application. > Using mapserver in a multithreaded environment should be handled with > care. I understand that. It's just what care I'm unsure of. > One should take into account the following issues: > > 1. Since these unmanaged dll-s are using shared (global) variables and > resources, multiple requests will use the same variables from > different threads, and should be protected by locks. Are you suggesting that we should protect access to the mapserver objects within the C# code, using the C# lock statement? Or are the locks within the mapscript_csharp.dll sufficient? > 2. Mapscript objects members are not syncronized by locks so passing > these objects between threads is to be avoided. 3. Mapscript objects > should be properly disposed if not needed any more. > Considering the previously mentioned facts we should draw at least the > following conclusions: > > 1. Thread support should be enabled when compiling mapserver and > mapscript C#. It will enable the locks on the shared variables for the > most important components. Some of the components are not protected > this way so those items should be avoided. See > http://mapserver.gis.umn.edu/docs/faq/thread_safety for more details. > 2. One should compile with only the features really needed by > the application. > 3. Should not retain mapscript objects between requests (eg. using in > session variables). > 4. Should use IDisposable.Dispose or the using{} clause to properly > deallocate the unmanaged memory. > > Some of these conclusions may also apply to other languages using > multithreaded application models. > > We are making some effort to eliminate the need of those variables and > using "big locks" to increase the performance of the applications in > multithreaded environments. To achieve this level most of the existing > code should be reviewed. The first step for this activity was recorded > at http://mapserver.gis.umn.edu/development/rfc/ms-rfc-15/ and will be > enhanced upon the user's and developer's affinity for this issue. I'm > considering few of the folks using mapserver and mapscript this way or > they aren't complaining about much of these problems so far. Google has changed things. Our customers are demanding mapping, and demanding a more interactive mapping capability than they'd previously been satisfied with. I think you'll see a growing interest in running mapscript with ASP.NET and ATLAS.
