On 30.10.2015 15:06, wm4 wrote:
On Fri, 30 Oct 2015 11:30:40 +0100
Tobias Rapp <t.r...@noa-archive.com> wrote:
On 29.10.2015 09:38, Tobias Rapp wrote:
Attached patch fixes file lock issues in my Windows application when a
child process is started with handle inheritance enabled (standard
input/output redirection) while a FFmpeg transcoding is running in the
parent process.
BTW: It would be great if the patch could also be applied to the 2.7/2.8
release branches.
Forgot to add links relevant to the subject.
[1] https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx
Describes the _wsopen() function and the O_NOINHERIT flag. File handles
opened by _wsopen() are inheritable by default.
[2]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
Describes the CreateFile() function. Not directly relevant here, often
used in cases outside of C/libc. Opens file without inheritance by
default (lpSecurityAttributes is NULL).
[3]
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
Describes handle inheritance when creating new processes. Handle
inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want
to pass handles for stdin/stdout via lpStartupInfo.
Would be great if you could put all this stuff into the commit message.
Have attached a more verbose version of the patch.
Would it make sense to define O_CLOEXEC to O_NOINHERIT on Windows?
Although to my knowledge O_CLOEXEC and O_NOINHERIT cause the same
behavior it would be confusing to trace when O_CLOEXEC maps to the
original Linux definition and when it maps to the Windows override when
reading source code. If someone finds it useful a definition like
FF_O_CLOEXEC could be added (to which file?) that maps to the correct
flag depending on the platform.
Regards,
Tobias
>From c2b599c18a173ce3a2f053701bc4ef1f14ef7aea Mon Sep 17 00:00:00 2001
From: Tobias Rapp <t.r...@noa-audio.com>
Date: Thu, 29 Oct 2015 09:11:37 +0100
Subject: [PATCH] avutil/file_open: avoid file handle inheritance on Windows
Avoids inheritance of file handles on Windows systems similar to the
O_CLOEXEC/FD_CLOEXEC flag on Linux.
Fixes file lock issues in Windows applications when a child process
is started with handle inheritance enabled (standard input/output
redirection) while a FFmpeg transcoding is running in the parent
process.
Links relevant to the subject:
https://msdn.microsoft.com/en-us/library/w7sa2b22.aspx
Describes the _wsopen() function and the O_NOINHERIT flag. File handles
opened by _wsopen() are inheritable by default.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425%28v=vs.85%29.aspx
Describes handle inheritance when creating new processes. Handle
inheritance must be enabled (bInheritHandles = TRUE) e.g. when you want
to pass handles for stdin/stdout via lpStartupInfo.
Signed-off-by: Tobias Rapp <t.r...@noa-audio.com>
---
libavutil/file_open.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/file_open.c b/libavutil/file_open.c
index 3f9a67c..9e76127 100644
--- a/libavutil/file_open.c
+++ b/libavutil/file_open.c
@@ -77,6 +77,9 @@ int avpriv_open(const char *filename, int flags, ...)
#ifdef O_CLOEXEC
flags |= O_CLOEXEC;
#endif
+#ifdef O_NOINHERIT
+ flags |= O_NOINHERIT;
+#endif
fd = open(filename, flags, mode);
#if HAVE_FCNTL
--
1.9.1
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
