[Gdal-dev] Motion to Adopt RFC 16: OGR Thread Safety

[mchapman at texelinc.com]

I agree.  Adding mt to gdal should be done at the application level.  That's what I do today and it works great.  You could also consider thread safe wrapper classes instead of modifying the core.  Simon's idea of a lock/unlock is good too.

Martin

Sent via BlackBerry by AT&T

-----Original Message-----
From: Simon Perkins <sy at perkins.net>

Date: Sat, 06 Oct 2007 11:17:01 
To:Frank Warmerdam <warmerdam at pobox.com>
Cc:gdal-dev <gdal-dev at lists.maptools.org>
Subject: Re: [Gdal-dev] Motion to Adopt RFC 16: OGR Thread Safety


For some reason I missed or ignored the original posting of this RFC. I 
have a late comment / question...

What about methods that modify a layer? i.e. we have two threads, A and 
B accessing the same layer via layer clones, so they each have their own 
read state. What if thread A checks to see if a feature with FID 42 
exists, then B invokes a method to delete feature 42, before thread B 
attempts to get the geometry for that feature? Even if those calls are 
serialized, it is likely that thread A will get very confused.

I think in general, guaranteeing thread safety when you have threads 
modifying data is in general extremely hard at the library level, and 
really requires some kind of thread coordination at the application 
program level. Maybe the datasource mutex could be exposed with a couple 
of handy Lock/Unlock methods to make this kind of high level 
coordination easier? In any case, shouldn't the RFC mention something 
about reading vs writing?

Cheers,

Simon


Frank Warmerdam wrote:
> Motion: To adopt RFC 16: OGR Thread Safety
>
> http://trac.osgeo.org/gdal/wiki/rfc16_ogr_reentrancy
>
> ---
>
> There wasn't to much discussion on this as far as I recall, which I take
> to mean no one has a problem with it.  So moving to formal vote so I can
> implement this coming week.
>
> +1 from me.
>
> Best regards,

_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev