> It shouldn't be too hard. Assuming you handle the modify channel as a > synchronous action, the thread calling modify channel can't also be in > rdma_get_cm_event at the same time. So, if you get there and someone is > blocking on that channel and just hasn't been scheduled to run yet, then > leave the event where it is while you switch the channel and send new > events to the new channel. If they aren't then move any pending events > to the new channel as you do the change. Hmm, how do you move events? Keep in mind that there may be an arbitrary number of pending events that belong to other cm_ids that are queued before the events you want to move. And you can't really do anything too funky with the event channel fd, because you don't want to mess up some other thread that might be waiting for events in poll() or whatever. - R. _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
| Jens Axboe | Re: [BUG] New Kernel Bugs |
| KAMEZAWA Hiroyuki | Re: 2.6.24-rc3-mm1 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Jarek Poplawski | Re: [BUG #12364] Re: HTB - very bad precision? HFSC works fine! 2.6.28 |
| Alexey Dobriyan | Re: [GIT]: Networking |
