-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ignore SIGPIPE in send() and recv() #101
base: master
Are you sure you want to change the base?
Conversation
…eceiving EPIPE This solution is intended to solve issue s-u#100. The method is very similar to what is being done in the internal R http server (see Rhttpd.c). It should therefore not cause any issues in other parts of R.
When is this PR going to happen? SIGPIPE errors are the bane of my life right now. |
To turn around, ou can try to encapsulate the R call which generate the bug with a try(), or use some redirection of output & error streams using sink() before... |
Hi Yann,
Using try() will not work.
The issue occurs on a forced disconnect from client A, which results in
SIGPIPE and the deletion of the tmpdir (also for all other clients). This
occurs independent of the R code that rserve is executing.
Kr
Ruben Faelens
Op do 30 aug. 2018 08:52 schreef Yann Richet <[email protected]>:
… To turn around, ou can try to encapsulate the R call which generate the
bug with a try(), or use some redirection of output & error streams using
sink() before...
In some cases, it will be sufficient.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#101 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABUOgvTkr8Pk_cuVHqlpbZaf8CRjRCBaks5uV4uPgaJpZM4Sj_le>
.
|
Well, the problem is a bit more complicated - officially, it's impossible to handle We are working on a more clean solution in R where R would allow packages to register certain handlers (like That said, I think you're trying to solve the wrong problem - you cannot in general prevent R shutdown, so this is just one of may ways you ca get there - I'd recommend the approach I outlined in the issue - make sure each child has it's own |
Thanks for the comment! I agree with you. src/library/tools/R/sotools.R
specifically mentions symbol R_ignore_SIGPIPE as non-API.
Changing tempdir is the appropriate work-around for now, by using
unixtools::set.tempdir(). However, the directory should not have the
initial Sys_TempDir as parent, otherwise it will still be removed...
See e.g. https://www.rforge.net/doc/packages/unixtools/set.tempdir.html where
the example code unfortunately does exactly that.
The SIGPIPE occurs when Rserve is writing a response to the Rserve client.
This is outside of any R execution.
Upon SIGPIPE, R eventually calls R_CleanTempDir() (defined in
src/unix/sys-std.c).
This function performs rm -rf Sys_TempDir.
Sys_TempDir is initialized in R_reInitTempDir() (defined in
main/sysutils.c)
This function is only called by InitTempDir()
Which is only called by setup_Rmainloop()
So you cannot change the directory which finally gets deleted. You can only
change the tempdir of the current session.
…On Thu, Aug 30, 2018 at 2:54 PM Simon Urbanek ***@***.***> wrote:
Well, the problem is a bit more complicated - officially, it's impossible
to handle SIGPIPE properly without support from R itself, because it will
replace the handler with its own version. Your approach here doesn't work,
because R_ignore_SIGPIPE is not part of the API and thus cannot be used.
That piece is only used by the internal HTTP server.
We are working on a more clean solution in R where R would allow packages
to register certain handlers (like SIGCHLD or SIGPIPE) in a way that
makes it possible to manipulate the handlers in different situations
automatically.
That said, I think you're trying to solve the wrong problem - you cannot
in general prevent R shutdown, so this is just one of may ways you ca get
there - I'd recommend the approach I outlined in the issue - make sure each
child has it's own tempdir - it's much safer in many ways that that's
what we use.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#101 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABUOgrwTsuOE9WgtafADiS4LAvHAKKupks5uV-B9gaJpZM4Sj_le>
.
|
This solution is intended to solve issue #100. The method is very similar
to what is being done in the internal R http server (see Rhttpd.c).
It should therefore not cause any issues in other parts of R.