fre 2008-04-11 klockan 10:52 -0600 skrev Alex Rousskov: > A comm_cancel_my_read wrapper will help mitigate risk (but not eliminate > it). Note that once the comm_cancel_my_read is in place, the only > mistake the programmer can make is to call Call::cancel instead of > calling comm_cancel_my_read. The effect? Comm may poll the FD one extra > time. We are not risking much here, right?
right. but there is one more race here.. comm_read -> comm_read_cancel -> another comm_read. What happens with data which the first had already read from the fd? Fortunately comm_read_cancel isn't used in situations where it really matters, but it's a general problem which is helpful to discuss now rather than when it bites.. > I suggest that we rename comm_read_cancel and others t and add a > callback reference parameter to make sure that all code supplies the > stored callback to be canceled (with a firm guarantee!). If some code > does not have a stored callback, it would have to call > comm_read_cancel_if_not_too_late() instead, which may prompt the > developer or reviewer to think "What if it is too late?". Fine by me. or we could spend a couple of minutes and make the callback based comm_read interact properly with the callback based comm_read_cancel. - Add another comm reference to the Call (recipient) - Make the call being dialed via a comm jumpgate which notes that it has been dialed (clears the other Call referene) and then calls the original recipient. making the callback based comm_read_cancel 1. cancel the recipient "side" of the call 2. cancel the comm operation And similar for callback based commSetTimeout() But if they are all converted over to the AsyncCall based comm interface this isn't a problem. > Cancel_my_foo wrappers solve that problem. Only one action is required. Yes. > > Or we could get rid of comm_read_cancel entirely.. at least when dealing > > with AsyncCall based comm_read calls. > > All comm_read calls are AsyncCall based, I think. Some calls are created > dynamically/internally (perhaps that is what you mean). That's what I mean. > The > corresponding readers will have to be either updated or use > comm_read_cancel_if_not_too_late. Otherwise, they will not compile. > > > And we had a similar race in comm_close earlier if you remember. > > Yes, I do. And we would had another "race" in comm_cancel_write if comm > implemented that (it should, but that is a different story). When would one want to (in the protocols we deal with) cancel a write without closing the fd? > The only disagreement I detected is about tying AsyncCall and Comm via > Call::cancel(). Did I manage to convince you that simple wrappers like > comm_cancel_my_read are better than tying the two tightly with the > Call::cancel code? Yes. Regards Henrik
