Ignore SIGPIPE in send() and recv()

[rfaelens]

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.

[karlroberts]

When is this PR going to happen? SIGPIPE errors are the bane of my life right now.

[yannrichet]

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.

[rfaelens]

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 <notifications@github.com>:

…

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> .

[s-u]

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.

[rfaelens]

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> .