RFC 16: MapScript WxS Services

[Tamas Szekeres]

Frank,

SWIG Mapscript exposes its functionality as object oriented interface model,
however the mapserver code is implemented using conventional C code.
Theoretically when an user invokes a method of an object she expects that
this call will not violate and interfere with other invocations of other
objects. With the current implementation one has a good reason fear of it.
Using locks around global variables will keep up the appearance that the
threads are separated, but kills the performance and scalability of the code
and still not separated in effect.
In fact the separated mapscript objects should be really separated. That was
the primary reason that called RFC-15 to be created. 

>Note, I have proposed making the msIO handers thread local, so that each
>thread can have independent handling of output routing.

Using thread locals to separate object invocations as a replacement of the
global ones are considered as a makeshift and -in quality- highly lags
behind using local contexts. For example one day if the folks will find out
the need to pass objects between threads we will be between hell and
high-water. It is not too unrealistic because some of the application models
will use different threads between subsequent requests without having the
control of the developer. Developers might want to maintain the state
between requests.

>This would require changing and reviewing and modifying an enormous
>amount of code.  For me it just is not on the table.  And I am not clear
>on what the benefit would be.

I don't think so. The possible solution is inside the code since it is
prepared to use contexts along with the io operation. 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)
3. Return the result from the context as gdBuffer

>I would add that the cgiRequestObj currently is just used to manage
>a set of name/value pairs and I don't think it would be a reasonable
>"univeral io context".

Agreed, let's bring in a new parameter


>I have implemented thread local support the errorObj in maperror.c, and
>lacking core "thread local" services from libmap, I would just use a
>similar
>approach.  I am a bit concerned about performance overhead for higher level
>code that might be doing a lot of very small msIO calls as each call will
>require an extra few layers of indirection and a search for the threadlocal
>io handlers in a linked list.

Has globals and locks mentioned before.

>I would say that I am concerned that the proposed approach to install and
>reset io handlers isn't all that clean and extendible.  If I install a
>msIO buffer handler, and then call a function that wants to temporarily
>install a different handler, it is clumsy for it to restore the old
>state properly.  Currently I don't forsee much need for that, but even
>the current approach means that some care needs to be taken to reset
>msio handlers when processing a buffered request is done.

Yeah, so we have the possibility to put at least one portion of the code
into a good shape, it would be unwise to loose it.

Frank, since I am determined to carry on RFC-15, i am ready to dig into this
issue in more deatail to help - if needed. 


Best Regards,

Tamas



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.5.6/337 - Release Date: 2006.05.11.