On Wed, Mar 4, 2020 at 4:09 PM Ian Lance Taylor wrote:
>
> The links that I looked at were speculating about behavior, not
> demonstrating real behavior in kernels. I don't know how to judge
> whether those speculations about hypothetical behavior are correct or
> not. Many things are hypothetic
Thanks for the feedback.
> "If the close operation fails to close fildes2, dup2() shall return -1
> without changing the open file description to which fildes2 refers."
> "If close() is interrupted by a signal that is to be caught, it shall return
> -1 with errno set to [EINTR] and the state of
On Sun, Mar 1, 2020 at 3:55 PM Ian Lance Taylor wrote:
>
> If dup2 can 1) close newfd; 2) receive a signal before duping oldfd to
> newfd; 3) return EINTR leaving newfd closed, then dup2 requires
> considerable care in any multi-threaded program. It requires that if
> one thread is calling dup2,
On Sun, Mar 1, 2020 at 3:06 AM Ian Lance Taylor wrote:
>
> > But if you opened newfd yourself, or if it is 0/1/2 and you never
> > closed os.Std*, then you *can* dup2 safely, regardless of other
> > packages.
>
> Those are examples where you are in charge of the FD namespace
> (assuming you know t
> If you are getting an error nothing has happened, no replacement of newfd and
> no close
I wish that sentence was written on the man page.
That was the way I first understood it too (and it makes more sense)
but the little information I found disagree (libuv [1], python [2]
(see the note about
On Sat, Feb 29, 2020 at 9:13 PM Brian Candler wrote:
>
> I don't quite follow. If two threads are fighting to use the target fd, then
> that's just a race anyway.
One case is when you have full control of the FD namespace, then you
can rely on your own synchronization and do whatever you want,
On Sat, Feb 29, 2020 at 4:35 PM Uli Kunitz wrote:
>
> My reading of the Linux kernel sources (5.3) is that dup2 will never return
> -EINTR.
Thanks, good to know.
> But you will have to program the loop around the syscall anyway, because
> Linux may return EBUSY, which happens if the new fd has
On Sat, Feb 29, 2020 at 3:41 PM Manlio Perillo wrote:
>
> What about using fcntl with F_DUPFD?
> [...]
> It does not have the problems of dup2 where you can use an already in use fd,
> and unlike dup you can specify where the new fd should be allocated.
Thanks, good to know and may come in handy
On Sat, Feb 29, 2020 at 1:34 PM Ian Lance Taylor wrote:
>
> It does not make sense to use dup2 if you are not in control of the FD
> namespace. In order to use dup2 you need to specify the new FD. If
> that FD might be concurrently opened by some other package, or by the
> runtime, then you can
Thanks for the reply.
> Note that dup2() can only fail with EINTR if the new fd is currently open on
> a "slow" device and the implicit close() fails due to being interrupted.
I understand the condition may be rare, but I still want to know the
correct way to handle it.
> In my experience it is
> > log.Fatal and os.Exit have the same problem. They are not "terminating
> > statements", so if you want them at the bottom of a function with result
> > parameters you have to add a panic("unreachable").
>
> Excellent point. But contemplating being able to declare library functions
> termina
On Mon, Jan 13, 2020 at 3:07 AM Ian Lance Taylor wrote:
> The difference between os.Stdout and other files is: if writing to
> os.Stdout fails, where are you going to report the error? You could
> report it to os.Stderr, of course, but if os.Stdout doesn't work then
> it is very likely that os.S
12 matches
Mail list logo
