Hi Tim, On 10:53 Thu 01 Nov , Timothy A. Meier wrote: > > > > I think we need to close threading issue first. Then patch series of 2 > > looks fine for me. > > > > > I really think the "thread-per-session" would be a more flexible and > powerful > design. Setting up and maintaining threads might seem more complex at first, > but it makes servicing requests/commands much more simple because everything > is > in its own context.
And require proper locking, thread termination handling, etc.. Which is not always easy even with full featured pthread library, and especially hard with limited cl_thread*() primitives... I didn't analyze submitted code in this aspect - just tried to save the time... :) > The previous Console used a polling mechanism, and I found an edge case > condition > which allowed one connection to block the other. How? There is no "blocking" commands? Right? > Thread-per-session (or > thread > per connection) makes it difficult for one session to influence another. > > The number of threads/connections would be limited. Other than the normal > multi-threading issues, are there other thread hazards in OFED/OpenSM that I > need to be aware of? Another reason is to not get too much cpus from another OpenSM threads (which mainly are responsible for IB MADs processing). Sasha _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
