On 04/17/12 21:38, Chris Mason wrote:
On Tue, Apr 17, 2012 at 03:36:20PM -0400, Josef Bacik wrote:
Well then passing a flag down that says we can't interrupt I guess is what we're
going to have to do and just wait uninterruptible. I think our best bet is to
just fix them as they come up, I thought all system calls could return EINTR but
apparently I was wrong :). Thanks,
I'd guess that EINTR is unexpected most of the time. Including in reads
and writes. The real question is how long we might end up waiting?
EINTR is valid for both reads and writes. This was put into place when I would
run tests and get tired of waiting for them so I'd ctrl+c and it wouldn't stop
even though it's something that's completely stoppable. So I'd like to leave it
in there so at the very least I can still ctrl+c when I accidently run something
I don't want to run ;). Thanks,
Ok. lets just teach git how to eintr.
git known how to eintr, but just not on unlink. It'll be easy to add
that, but not even the manpage states EINTR as return value from unlink.
I'd go for Josef's solution and just make unlink non-interruptible,
adding more when they pop up.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
