On Thu, 2010-09-02 at 09:42 +0200, Michel Onoff wrote: > On 2010-08-30 15:59, Oleg Kalnichevski wrote: > > On Mon, 2010-08-30 at 15:09 +0200, Michel Onoff wrote: > >>> > >>> If that makes sense in the context of your application, go for it. > >>> ReadWriteLock is available in the j.u.concurrent package. All you have > >>> to do is to extend the default HttpConnection implementations, override > >>> public methods and make them acquire either read or write lock prior to > >>> calling the super method. > >>> > >> > >> Oleg, > >> > >> this assumes that DefaultHttp(Client|Server)Connection (a concrete > >> implementation) maintains no reading state that could interfere with > >> writing operations and no writing state that could influence reading > >> operations. > >> > >> Can you confirm that this is the case, before I start with coding? > >> > >> Thanks > >> MO > >> > >
... > Shouldn't this aspect be documented? I mean, not only in source code but > in the javadoc as well? After all, the tutorial insists that a > connection is not fully thread-safe but being full-duplex capable is > still of big help. > > At least, this solves my current concerns. > There are two possibilities, if you feel very strongly about it. (1) feel free to contribute patches for javadocs and the tutorial. A new section for the 'Advanced topics' chapter about thread-safe connections would probably make most sense. (2) consider contributing your custom implementations of Http(Server| Client)Connection interfaces to HttpCore > Thanks > MO > > --------------------------------------------------------------------- > 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]
