RFC 16: MapScript WxS Services

[Tamas Szekeres]

> I would claim there is a big difference between fine grained locks
> around updates to static stuff (like the maperror.c threadlocal related
> lock) and "big locks" such as the one around all GDAL access.  Big locks
> deny any other thread access to the service for a lengthy period while
> a big bunch of processing is done.  Fine grained locks only exclude
> other threads long enough to do a few assignments changing around a
> shared data structure.
>

Frank,

I can see the difference between the fine grained locks and the "big
locks", but in my opinion
common variable access and locks are somewhat to be avoided if it is
not really needed for the code.

> So, I would claim that fine grained locking, as proposed for maintaining
> the threadlocal "msIO" lists will not have a significant effect on performance
> or scalability.

I am not totally sure about this. I am not an expert of the various
standard io implementations, but AFAIK
only one stdout can be utilized for a process at a given time, however
it involves the need
for using processwide locks in the implementation. The multithreaded
CRT may be using various
level of locks inside the implementation falling outside of the
developers control and may result in
some additional unexpected issues.
Correct me if i got wrong.

>
> > In fact the separated mapscript objects should be really separated. That was
> > the primary reason that called RFC-15 to be created.
>
> I'm not sure what you mean by "mapscript objects should be really separated".
> To me RFC 15 is a survey of perceived multi-thread problems, with plans to
> fix some of them.  In general we need to be more serious about multi-threading
> issues in MapServer if we want to satisfy the multi-threaded user base.
>

I was also addressed the aim to eliminate the usage of the global
variables if it is
not required for a given portion of the code theoretically.

>
> I would add that the io context would need to be passed in a lot of
> mapscript code, and that we (the mapserver core developers) have no easy
> way to update the many mapscript applications out there in the world.
>

I don't think if the context would be propagated through the mapscript
interface. It should
remain as an internal state of the map object. As I can see much of
the functions calling
msIO_printf also have the reference to the map object, so the context could be
easily obtained. The context should also be initialized internally at
the beginning of the
OWSDispatch call.


> >To achieve the
> > requested behaviour the *only* following steps should be implemented.
> >
> > 1. OWSDispatch should initialize the context (msIOContext) adding a memory
> > writer as readWriteFunc (instead if msIO_stdioWrite). Context.cbData should
> > hold the accumulated result.
> > 2. Find and replace msIO_printf -s with for example msIO_printf_ctx -s
> > having the context as a parameter. (not all of the files having msIO_printf
> > should be modified eg. mapserv.c, cgiutil.c)
>
> Well, it is this step 2 that frightens me.  I would add that some of the
> output occurs in places like msSetError().  All sorts of functions at
> various levels would have to be re-engineered to pass around this io
> context.   It could be done, but I claim it is hard.
>

I don't think if we should replace all of the code according to this
issue since it is not harmful to use
the contexts along with the traditional stdio handling. I may be true
that this implementation is candidate
 to have a new RFC, but i am not sure if it would not require the need
to replace your current work
according to this implementation (i mean the thread local stdio). I
think this should be avoided.
The best option to write the code without leaving open issues with it.

I will not want to go against this change if you have not enough spare
space in your timeline to address such an issues.
A new feature that may be more convenient is better than the absence
of that feature.

Best Regards,

Tamas