Adrien Destugues 463ffbfde4 First steps towards cookie jar thread-safety
* Change the semantics of the iterators copy constructor and assignment
operator: they now return a new iterator for the same cookie jar (and
same url for the UrlIterator). They don't try to point to the same
position as the copied iterator. The only purpose of these is to write
code such as:

Iterator it = jar.GetIterator();

so having a full copy isn't that useful.

* The per-domain cookie lists are now protected with a read-write lock.
The iterators retain a read lock while they are handling cookies from
that list. They get a write lock when doing Remove. Adding a cookie to
the jar also gets the write lock for the matching list

* Fix a memory leak when adding a new domain-list to the jar failed

* Simplify the declaration of the PrivateHashMap type (it would be
even simpler if HashMap was a public API)

* The domain hashmap is now a SynchronizedHashMap. It is locked as long
as an Iterator or UrlIterator exists, which may be a problem as these
are public APIs. Writing safe iterators for an hashmap with concurrent
accesses is not easy, so the API could be modified to return a list of
domains and a list of cookies for a given domain or URL instead. This
would suit the intended uses just as well.

* The jar now store const cookies, so there is no need to lock them for
access/modification. Updating a cookie is done by replacing it with
another one in the jar (with the same domain and value). There is still
the problem of deleting a cookie while other threads may still access
it, this will be fixed by making cookies BReferenceable.
2014-06-11 12:59:33 +02:00
..
2013-11-04 20:16:05 -05:00
2014-02-22 13:51:55 +00:00
2014-06-04 11:56:23 +02:00
2014-01-13 08:05:32 +01:00