[ovs-dev] [ovsdb-server multithreading RFC 2/9] ovsdb: Make 'remote' opaque in ovsdb_jsonrpc_session

Ben Pfaff blp at ovn.org
Fri Mar 25 17:07:43 UTC 2016


On Mon, Mar 21, 2016 at 01:00:53PM -0700, Andy Zhou wrote:
> On Fri, Mar 18, 2016 at 5:20 PM, Ben Pfaff <blp at ovn.org> wrote:
> 
> > On Thu, Mar 03, 2016 at 12:13:21AM -0800, Andy Zhou wrote:
> > > It turns out there is no need for ovsdb_jsonrcp_session to have access
> >
> > s/jsonrcp/jsonrpc/
> >
> > > to the remote data structure. Make it opaque as a 'void *' pointer.
> > > The pointer value is still useful when selecting ovsdb_jsonrpc_sessions
> > > that of the same 'remote'.  This change will laster multi-threading
> >
> > s/laster/later/
> >
> > > patches easier because access to 'remote' does not need be protected.
> > >
> > > Signed-off-by: Andy Zhou <azhou at ovn.org>
> >
> > I am not sure I understand the benefit yet.  The definition of a struct
> > does not have to be visible for a piece of code to refer to it through a
> > pointer.  Also, using a void pointer loses a lot of type safety.
> >
> > Can you explain further?
> >
> 
> Yes, I agree this is a trade off.  Wonder if there is better way.
> 
> Currently 'remote' object are only handled within the main thread, so no
> locking
> is required to access those objects.  The intention of changing to 'void'
> is to avoid
> 'sessions thread' code accidentally dereference 'remote' object, thus cause
> race
> conditions.  I was thinking the trade off is worthwhile... Please let me
> know if you
> don't agree.

I think that there is probably a better way than a void pointer.
Usually, code can be arranged so that code that should not have a
visible definition does not; for example, by putting the definition
after the code that should not see the definition.  Is that difficult
here?



More information about the dev mailing list