RFC 16: MapScript WxS Services

[Frank Warmerdam]

Tamas Szekeres wrote:
> 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.

Tamas,

Agreed, but if it is needed...

>> 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.

By efforts at mutex protection in the msIO code are not aimed at
exclusive use of stdin, stdout or stderr, only at protect update of
the internal msIO datastructures for holding handlers.  Whether
multi-threaded output to stdout is supported will depend on the CRT
in use.  That is not changing.

>>
>> 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.

And yet, many functions doing output do not have access to a mapobj.
So there would still be api changes.   I'm also a bit nervous about
considering an io context an attribute of the map when I'm not at all
sure that is logical.  It would completely prevent sharing mapObj's
between threads in the future.

>> 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.

It is true that a proper "io context" overhaul would remove the need
for the msio (mapio.c) module.  However, my RFC isn't introducing
mapio.c, it already exists.  I'm just doing a small extension to use it
to "capture" output to a buffer.

> 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.

Right.

I'm sorry to be so defensive about my proposal.  It is just that I am
quite "risk averse".  I hesitate to change more than necessary because
there could be unexpected consequences to a broader change, and then I
will be "on the hook" to deal with them in the years to come.  And I'm
a very "backward compatibility" focused sort of person.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org