On Mon, 2009-02-02 at 22:44 +0000, sebb wrote: > Protocol Interceptors are supposed to be thread-safe. > > However, BasicHttpProcessor is not thread-safe as changes to the Lists > are not synchronized. > > The rest of the Interceptors have no fields so are immutable. They > operate on non-thread-safe classes, however I assume that such classes > are confined to a single thread. > > == > > SessionRequestImpl is supposed to be thread-safe, however there are > several mutable fields that are not synch or volatile. > > == > > Are HttpParams supposed to be shared between threads? The Javadoc say > that they are intended to be immutable once initialised; however this > does not guarantee that the values will be visible to all threads. > > BasicHttpParams could be made less thread unsafe by making the map > final, and clear()ing rather than null-ing it. > > Likewise, if there was a copy constructor, if could save the map > variable after creating it. >
(1) Both BasicHttpParams and BasicHttpProtocols can be shared between threads but they are expected to be used in the 'write once / read many' mode. Therefore, access to their internal structures is not synchronized for performance reason. These classes are not fully thread-safe if modified at runtime and any statement to the contrary is a mistake in documentation. I suggest we improve the documentation of BasicHttpParams and BasicHttpProtocols with regards to their intended usage, but will not make them fully thread-safe. Making those classes less prone to synchronization issues would also be welcome. Would that be okay for you? (2) I'll review SessionRequestImpl Oleg > S/// > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
