Libor Michalek wrote:
The other option is to destroy the connection if the consumer returns an error value from the callback.
I'll have to think about this. As a personal preference I try to avoid having callbacks return values. But then I'm not thrilled about passing in flags to destroy to handle this either.
Along the same lines, will the consumer be allowed to call the corresponding response function from
a callback? (e.g. ib_send_cm_rep() from the REQ callback) If not then
the same behaviour could also be achieved with a callback return value.
This is a goal of the implementation, and I don't foresee any reason why it can't be done.
* Should listening clients call an "accept" routine to wait for a connection request? Currently, the API operates asynchronously and inokves a CM event handler.
I don't think this is necessary. Presumably the biggest reason to use "accept" is to force the consumer to use its own thread to handle CM state changes, thus avoiding CM or MAD thread deadlock if there is a buggy consumer, or is there another reason to add this step?
I didn't think it was necessary either, but wanted to mention it as a possible idea.
However, a nice to have feature which I've grown use to is the ability to listen to an entire range of service IDs using a value/mask combo.
I'll add this. I saw the mask in the Topspin CM API, but didn't look into why it was there, so removed it.
Thanks for the feedback.
- Sean _______________________________________________ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
