Hacker News Reader

Comment by Sesse__ | Hacker News Reader

Standards aside, returning EINTR on a write to local file is extremely rare in POSIX.

Almost any syscall can return EINTR, but in practice, for all previous OSes, it has been reserved for those that can hang for an undetermined amount of time -- that is, anything from the network. Local I/O should complete in a bounded amount of time, so that kind of sleep is usually implemented as uninterruptable.

There's one highly relevant edge case: NFS. NFS looks like local I/O, but if the NFS server goes away, what do you do? Traditionally, the process just hangs in the hope that the server will come back, which leads to the dreaded issue of processes being stuck and unkillable. On Linux, can add the “intr” flag to the mount (possibly via a remount) to allow signals to interrupt the syscall and break the deadlock -- but then you break a ton of software, because, again, EINTR on local file I/O is unheard of.

View on HN

This EINTR is returned here for attempts at file accesses trapped by an antivirus/security layer, which can indeed take an undetermined amount of time, without the OS knowing how long that is...

Probably was a hard choice to make for Apple too. Should a thread be frozen for an undetermined amount of time while an antivirus does the check?

> Should a thread be frozen for an undetermined amount of time while an antivirus does the check?

Yes, certainly it should.

> Should a thread be frozen for an undetermined amount of time while an antivirus does the check?

It certainly does on other OSes and on previous versions of this one?

Do you really want to rewrite all existing software because it would be nice in 0.01% of cases that a thread is not "blocked" by an antivirus on file open, and can actually do something else, and that not on a specialized API but on good old syscalls? From a system design point of view that makes no sense.

> Do you really want to rewrite all existing software because it would be nice in 0.01% of cases that a thread is not "blocked" by an antivirus on file open

No. First, it's not a rewrite but a bugfix patch. Second, you will want this fix because open can return EINTR. It's documented. The code (postgresql in this case) is wrong. It should be fixed. simple.

POSIX is full of aspects that all OS provide greater guarantees or in some cases even deviates. It makes no sense to gratuitously / carelessly remove some of those guarantees and ask the world to fix their "obviously" broken programs that nevertheless worked perfectly on this (previously not really disputed) point during decades -- especially if the advantages such changes seem to be able to provide are not clear at all...

I'd surprise if a antivirus on windows would fail the read attempt from random software instead of temporary hang it. It will most-likely to be blamed as a bad AV here. Instead of just accepted because apple always do the correct thing.

It isn't a failure code, EINTR is a code that explicitly tells you to retry.

The equivalent API on Linux (https://man7.org/linux/man-pages/man7/fanotify.7.html), AFAIK, does block for an undetermined amount of time, and doesn't make the open() system call return EINTR.

> EINTR on a write to local file

Apparanty it was on an open() call on local file which is certainly ... unusual

https://www.postgresql.org/message-id/20210115210548.zfbnulf...

So, the old ‘Windows runs 50 year old software and therefore it drags along ancient api’ argument.

Welp, looks like it's happening now, so Postgres should fix it.

Reply on news.ycombinator.com