On Thu, Aug 21, 2025 at 03:07:57PM +0300, Vladimir Sementsov-Ogievskiy wrote: > What I dislike in the way, when we reset to blocking always, and set > non-blocking again where needed: > > 1. Extra fcntl calls for nothing (I think actually, in most cases, for > fds passed through migration stream(s) we'll want to keep fd as is) > > 2. When we reset to blocking on target, it's visible on source and may > break things. > > In these series it's probably doesn't really matter, as at the time when > we get the descriptor on target, it should not be used anymore on source. > > But for example, in CPR-transfer, where descriptors are passed in the > preliminary stage, and source is running and use the descriptors, we > shouldn't change the non-blocking status of fd on target. Probably, > CPR-transfer for now only works with fds which are blpcking, so we don't > have a problem. > > So, I think, that better default is preserve state of the flag for fds > passed through migration stream. And backends may modify it if needed (I > think, in most cases - they will not need).
I agree having that as a default iochannel behavior is questionable. If it was defined for any fd-passing protocols making sure nonblocking status is predictable (in this case, fds will be always blocking), IMHO it should be done in the protocol layer either constantly setting or clearing NONBLOCK flag before sending the fds, rather than having it silently processed in iochannel internals. Do we know how many existing users are relying such behavior? I wonder if we could still push this operation to the protocols that will need it, then we can avoid this slightly awkward iochannel feature flag, because the iochannel user will simply always have full control. -- Peter Xu
