RFC 16: MapScript WxS Services

[Tamas Szekeres]

2006/5/19, Stephen Woodbridge <woodbri at swoodbridge.com>:
> If Frank moves forward with this, does it make the work you are doing on
> threading significantly harder to do?
>

Steve,

I have only assumptions about Frank's implementation. As far as i know
he proposed to maintain variables needed to utilize the IO per thread,
but he would like to create a global repository for theese variables
requiring the need to synchronize the access between the threads. The
global repository would be accessed by the thread identifier as a key.
That was the main objection i have mentioned before since it goes
against the thread independency. However i would rather like to see
this feature - using this way - than completely leave this area
missing for mapscript.

>
> Clearly if we are moving mapserver to a more thread neutral
> implementation then all current?/future development needs to be
> implemented along the evolving thread neutral standards (whatever they
> might be). Someone should probably take a stab at writing up what these
> are as an rfc for approval - Tamas?
>

Well the rule of thumb to achieve this level of operation is simple,
but to reconstruct the existing code this way is more painful. That's
why my RFC will be a long lived and continously evolved proposal,
ensuring this issue to be kept in the foreground. Every areas
identified there requires a detailed analyzation of the code. If we
have to make a high number of modifications at an area it might be
better to retain the existing code and keep the access to the global
resources sychronized or suggesting to avoid that area for the user.
It must be noted that the current proposal is not the case of the
"future developments", since it brings in large amount of the existing
code with minor modifications, and Frank will not want to modify it
more than it is really needed for the functionality (it is not true
exactly because he wanted to make the aforementioned threading
concept).

In this case we have to consider the following issues:

1. The current WxS implementation has a large amount of the existing
code would be difficult to recreate from scratch.
2. The current WxS implementation comes from the cgi world having the
(global) standard output as the primary output interface. Therefore
the current msIO invocations do not have an additional parameter for
passing back the return value (io context in our previous terminology)
3. Using this additional parameter would require a large amount of
change, and we should propagate this parameter through the entire call
stack until the OWSDispatch call. I did not consider if this context
should be go outside of the mapscript call if the result is created
within the same call and an appropriate output structure can be filled
(gdBuffer was mentioned for this purpose). With this issue i was a bit
optimistic because the io context could be implemented easily at the
mapio.c side, but the large number of invocations makes this work much
more complicated.

Frank,

Have you consider to implement a real thread local io context using
the TLS api? If we could create the variables collecting the output
stream as thread local at the beginning of the OWSDispatch call and we
would not want to retain this variable between the OWSDispatch calls
we could have an equivalent implementation as passing the local
contexts between the function calls. As far as i know the TLS api does
not involve unnecessary synchronizations between the threads.


Best regards

Tamas Szekeres