On Thu, 2012-04-12 at 13:45 +0200, Jakub Hrozek wrote: > On Tue, Apr 10, 2012 at 08:21:32AM -0400, Simo Sorce wrote: > > On Tue, 2012-04-10 at 05:36 -0400, Jakub Hrozek wrote: > > > Andreas, can you check the src/util/util.c hunk in the first patch? I > > > think the atomic io functions were taken from libssh that you maintain.. > > > > > > Honza, can you check out if I didn't miss anything in sss_ssh_knownproxy > > > and if it can in fact use the atomic read? > > > > > > [PATCH 1/3] sss_atomic_io: Do not fail reads with EPIPE if there is not > > > enough data to read > > > The hunk in src/util/util.c would apply when the read buffer is bigger > > > than the contents of the file we read from. The rest is just unit tests. > > > > > > [PATCH 2/3] Move atomic io function to a separate module > > > We'll be using it on various places of the SSSD. The function is in its > > > own file to allow using just the one piece without having to drag in the > > > whole util.c module. > > > There is no functional change in this patch > > > > > > [PATCH 3/3] Convert read and write operations to sss_atomic_read > > > https://fedorahosted.org/sssd/ticket/1209 > > > > > > There are two exceptions that were not converted - one is the read in > > > sss_ssh_knownproxy because sss_ssh_knownproxy uses its own poll logic > > > that seemed to interfere with what atomic_read_does. The other are read > > > and write loops in the sss_client. Those use a logic as to how many bytes > > > are left to read and also handle polling themselves. > > > > Can we call these functions "blocking_io" instead of atomic_io ? > > We need to make very clear these functions do block potentially for a > > long time and cannot be used in the async code paths. > > > > I agree, but "blocking_io" seems too strong to me, what about a _s > suffix (like in openldap) and a comment in the header? See attached > patches.
I think you may have sent the old patches. These don't include either of the changes you proposed (at a quick glance).
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
