PyO3
Better error when compiled artifacts are in use
I was thinking the other day it might be nice to check if any processes are using the installed extension before attempting to copy across.
I think on Windows we'll get an OsError raised during copy, and on Unix any running processes are just likely to crash when they next need to load a segment of the native code.
Doing a check and raising our own friendly error might be nicer UX.
on Unix any running processes are just likely to crash when they next need to load a segment of the native code.
I think on Unix, you will get ETXTBSY if you modify a currently running executable in place:
loop-forever> ./target/debug/loop-forever >/dev/null &
[1] 22032
loop-forever> echo "foobar" > target/debug/loop-forever
bash: target/debug/loop-forever: Text file busy
Though this is not completely reliable and might be removed in the future, c.f. https://lwn.net/Articles/866493/
Depending on how copying files is actually done, this might also not be a problem at all, i.e. if the new file is moved to replace the old one, then there is no issue as the old file sticks around until no more process has it opened.
Oh, good to know. I think when I've seen segfaults before it was for libraries rather than executables. Might behave differently?
This is just a "nice to have" thing for development so I probably won't try to implement this any time soon. Just a passing thought.
I think when I've seen segfaults before it was for libraries rather than executables. Might behave differently?
I think this mostly happens because updates are not transactional, e.g. an older executable will after having been started dynamically load a newer library that has an different ABI the older version of the library. But as written above, ETXTBSY was never completely reliable.
From the article you linked above:
The MAP_DENYWRITE flag was created for just this use case, so that shared libraries could not be written while in use. When MAP_DENYWRITE went away, so did that protection; current Linux systems will happily allow a suitably privileged user to overwrite in-use, shared libraries.
It really does sound to me like shared libraries don't get ETXTBSY protection 😊
Indeed, the removal seems to be further along than I remembered from reading the article. Appears like I did not read it very thoroughly. 😊
So for extensions modules which are shared libraries ETXTBSY is irrelevant. Sorry for the noise...
Not at all! Always worth sharing information and debating my spurious claims of segfaults 😂