Discussion:
[asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec
Philippe Leuba
2014-05-20 15:24:32 UTC
Permalink
Hi,

How can we prevent Asio TCP socket to be inherited by child process when using fork/exec. Normally this can be achieved by adding the SOCK_CLOEXEC flag at socket creation time.

Adding the O_CLOEXEC flag later is not really a solution due to potential race conditions.

Creating the socket outside of boost and assigning it to the boost::ip::tcp::socket neither because async_connect will close it and open a new one.

Any others ideas?

Philippe Leuba
Gruenke,Matt
2014-05-20 18:33:32 UTC
Permalink
Race conditions at what level? If your fork/exec is not synchronized with your socket creation & configuration, then there’s a race condition even if you set it immediately after opening it.


Matt


From: Philippe Leuba [mailto:***@swissonline.ch]
Sent: May 20, 2014 11:25
To: asio-***@lists.sourceforge.net
Subject: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec

Hi,

How can we prevent Asio TCP socket to be inherited by child process when using fork/exec. Normally this can be achieved by adding the SOCK_CLOEXEC flag at socket creation time.

Adding the O_CLOEXEC flag later is not really a solution due to potential race conditions.

Creating the socket outside of boost and assigning it to the boost::ip::tcp::socket neither because async_connect will close it and open a new one.

Any others ideas?

Philippe Leuba

________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
Philippe Leuba
2014-05-20 19:27:26 UTC
Permalink
Hi,

For what I have understood, the SOCK_CLOEXEC flag is especially intended to set the close-on-exec flag atomically at socket creation time: socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP).

But how to do this with Asio?

Philippe Leuba

> On 20 mai 2014, at 20:33, "Gruenke,Matt" <***@Tycoint.com> wrote:
>
> Race conditions at what level? If your fork/exec is not synchronized with your socket creation & configuration, then there’s a race condition even if you set it immediately after opening it.
>
>
> Matt
>
>
> From: Philippe Leuba [mailto:***@swissonline.ch]
> Sent: May 20, 2014 11:25
> To: asio-***@lists.sourceforge.net
> Subject: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec
>
> Hi,
>
> How can we prevent Asio TCP socket to be inherited by child process when using fork/exec. Normally this can be achieved by adding the SOCK_CLOEXEC flag at socket creation time.
>
> Adding the O_CLOEXEC flag later is not really a solution due to potential race conditions.
>
> Creating the socket outside of boost and assigning it to the boost::ip::tcp::socket neither because async_connect will close it and open a new one.
>
> Any others ideas?
>
> Philippe Leuba
>
>
> This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
svante karlsson
2014-05-20 20:15:12 UTC
Permalink
Why would you use fork/exec at all? If you use asio then there is no need
to fork to implement a server that handles many concurrent connections.

/svante




2014-05-20 21:27 GMT+02:00 Philippe Leuba <***@swissonline.ch>:

> Hi,
>
> For what I have understood, the SOCK_CLOEXEC flag is especially intended
> to set the close-on-exec flag atomically at socket creation time:
> socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP).
>
> But how to do this with Asio?
>
> Philippe Leuba
>
> On 20 mai 2014, at 20:33, "Gruenke,Matt" <***@Tycoint.com> wrote:
>
> Race conditions at what level? If your fork/exec is not synchronized
> with your socket creation & configuration, then there’s a race condition
> even if you set it immediately after opening it.
>
>
>
>
>
> Matt
>
>
>
>
>
> *From:* Philippe Leuba [mailto:***@swissonline.ch<***@swissonline.ch>]
>
> *Sent:* May 20, 2014 11:25
> *To:* asio-***@lists.sourceforge.net
> *Subject:* [asio-users] How to prevent Asio TCP socket to be inherited by
> child when using fork/exec
>
>
>
> Hi,
>
>
>
> How can we prevent Asio TCP socket to be inherited by child process when
> using fork/exec. Normally this can be achieved by adding the SOCK_CLOEXEC
> flag at socket creation time.
>
>
>
> Adding the O_CLOEXEC flag later is not really a solution due to potential
> race conditions.
>
>
>
> Creating the socket outside of boost and assigning it to the
> boost::ip::tcp::socket neither because async_connect will close it and open
> a new one.
>
>
>
> Any others ideas?
>
> Philippe Leuba
>
> ------------------------------
>
> This e-mail contains privileged and confidential information intended for
> the use of the addressees named above. If you are not the intended
> recipient of this e-mail, you are hereby notified that you must not
> disseminate, copy or take any action in respect of any information
> contained in it. If you have received this e-mail in error, please notify
> the sender immediately by e-mail and immediately destroy this e-mail and
> its attachments.
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
>
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>
>
Gruenke,Matt
2014-05-20 22:38:27 UTC
Permalink
fork() + exec() is necessary to spawn another program, on UNIX-like systems. First, you fork(), which duplicates the memory image of the parent process (and increases the refcount on things like file descriptors and sockets). Then, the child process calls exec(), which replaces its memory image with that of a new program and executes it. If the child process is short-lived, then the extra refcounts on the file descriptors should be pretty harmless. But, if it’s long-lived, then I can see how they could be problematic.

I’m just not knowledgeable enough of ASIO’s architecture to answer it off-hand, though I expect it probably has the requisite flexibility. I’d track down how your sockets are getting created, then follow where the flags are coming from. It seems to me (and I’m unfortunately looking at a slightly outdated version) that you want to modify ip::tcp::type(). Or, perhaps subclass from it, override that function, and instantiate your sockets with your derived type.

Even if that works, it’s not necessarily the best way to do it. Socket creation happens in detail::socket_ops. detail::reactive_socket_service<typename Protocol, typename Reactor> is what calls that. If you follow the call-chain up, you might find a better place to substitute a type, in order to perform the desired customization.


Matt


From: svante karlsson [mailto:***@csi.se]
Sent: May 20, 2014 16:15
To: Unname
Subject: Re: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec

Why would you use fork/exec at all? If you use asio then there is no need to fork to implement a server that handles many concurrent connections.

/svante



2014-05-20 21:27 GMT+02:00 Philippe Leuba <***@swissonline.ch<mailto:***@swissonline.ch>>:
Hi,

For what I have understood, the SOCK_CLOEXEC flag is especially intended to set the close-on-exec flag atomically at socket creation time: socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP).

But how to do this with Asio?

Philippe Leuba

On 20 mai 2014, at 20:33, "Gruenke,Matt" <***@Tycoint.com<mailto:***@Tycoint.com>> wrote:
Race conditions at what level? If your fork/exec is not synchronized with your socket creation & configuration, then there’s a race condition even if you set it immediately after opening it.


Matt


From: Philippe Leuba [mailto:***@swissonline.ch]
Sent: May 20, 2014 11:25
To: asio-***@lists.sourceforge.net<mailto:asio-***@lists.sourceforge.net>
Subject: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec

Hi,

How can we prevent Asio TCP socket to be inherited by child process when using fork/exec. Normally this can be achieved by adding the SOCK_CLOEXEC flag at socket creation time.

Adding the O_CLOEXEC flag later is not really a solution due to potential race conditions.

Creating the socket outside of boost and assigning it to the boost::ip::tcp::socket neither because async_connect will close it and open a new one.

Any others ideas?

Philippe Leuba

________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs<http://cp.mcafee.com/d/avndygw96QmbTsh7nvd79KVJeXxEVuoouvsdFT78EIIEIc6QXK6zBVxxVZUSDssye7ce8TdGAoJ_0HUaCmJmk9YKrCmJmk9YKrjsu841Pb_nV5WWdQuLsKyMMeVdMs-UeVqWdAklrILYG7DR8OJMddECT3t-hojuv78I9CzATsS03mWzL0TaeJUcqTrMHF2xLqiGnrFYq5O5mUm-wafBiteFlKdLt00_MddEKcK8CMnWhEwdbuQBkKTjUQdbFEw2Zj1EwDkQgbhYPY9Cy0gFaFEw18A5zh1iJyLPd44WCy0xVEwB0DYpjZ0Qg42NEwIjAuwq831fU6y1KAE4jh0Xm9nf3_Ird7b9Ji1vZd44>
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net<mailto:asio-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/asio-users<http://cp.mcafee.com/d/FZsS83gOcxNJ5yZT4hRTPhOrKrjKUqenC67DT3qtNOabbab31JeXxEVuoouvudFT78zxP3ydPqF6bvMa-2FBHlB2vbCVBHlB2vbCQT7y10sO_R-huKzt7HTbEIc3Kjs7fK3KmKzp55mXb_axVZicHs3jqpJMTvAm4TDNOb2pEVdTdAVPmEBC7OFeDkGT6TKw0vU6UvaAWovaAVgtHCQBkKTjUQdXiliXtfzgKgGT2TQ1hYGjFRaJNJXE07-1FJ5NBN4S2_id41FrSAGBSWv6xFtd40nGod44WCy1qfCvxcQg259ld4094wIq8alIl-pEwDkQg4fd44E4_zavE6y0wmd45yszQ3h0o9_0QgdQB0yq87qNaVUvZzpEVpdxxCdVcOhr6sr>
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio<http://cp.mcafee.com/d/5fHCNAi6x0idEInKUyeK-qejtPqtT3hOYMMY-UrjKehhpphoodFTsd7bP33PXNJeUV4seoshKrl8Nr-1nMlcJqIEjVsTcJqIEjVsSCUYg83Cn-LObRQrEZuVt5xwtOrwVZMtORQr8EGTpvVkffGhBrwqrpdK6XYyMCY-ehojd79KVI07cDa1kLJ2QbsLwxils0kDkdE4Wiwh4aiGrSAGBSWv6xsxlK5LE2zVkDjGlrzrTg0fY3jqbzby9I5-Aq83iTJ9lbJQ-d3iWq80LkMq89Rd42Qvc_2pEw4aiGq80i91oQgkHoHYPh1eFEw8uq89g9_6k_gd410Iq8b4V7E6y0Mj-1EwrFa14QgeRylPM_X6PhOOr3cHUypBdj0V>

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs<http://cp.mcafee.com/d/2DRPoOd38O86QmbTsh7nvd79KVJeXxEVuoouvsdFT78EIIEIc6QXK6zBVxxVZUSDssye7ce8TdGAoJ_0HUaCmJmk9YKrCmJmk9YKrjsu841Pb_nV5WWdQuLsKyMMeVdMs-UeVqWdAklrILYG7DR8OJMddI6T3t-hojuv78I9CzATsS03mWzL0TaeJUcqTrMHF2xLqiGnrFYq5O5mUm-wafBiteFlKdLt00_MddEKcK8CMnWhEwdbuQBkKTjUQdbFEw2Zj1EwDkQgbhYPY9Cy0gFaFEw18A5zh1iJyLPd44WCy0xVEwB0DYpjZ0Qg42NEwIjAuwq831fU6y1KAE4jh0Xm9nf3_Ird7b9LFbrAt5M>
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net<mailto:asio-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/asio-users<http://cp.mcafee.com/d/k-Kr4zqb5XK8zHLCzATsSDtMQsLccffK6QXzAkmmkm63qtT3hOYMMY-YrjKeh73C74rCRicm_wlY5jbmHa4-ndPbmHa4-ndFKf420VB_HYyZt6WfnKnhoo7sCUevs7sJt6OaaJSn-l3PWApmU6CTPrxK_8I9LfzAm4PhOrKr9PCJhbcfBiteFlKdLt00_MdM-l9QM-l9OwXndFaFtKDNErSAGBSWv6xsxlK5LE2zVkDjGlrzrTg0fY3jqbzby9I5-Aq83iTJ9lbJQ-d3iWq80LkMq89Rd42Qvc_2pEw4aiGq80i91oQgkHoHYPh1eFEw8uq89g9_6k_gd410Iq8b4V7E6y0Mj-1EwrFa14QgeRylPM_X6PhOOrQHpQQL__i5g>
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio<http://cp.mcafee.com/d/FZsS96QmbTsh7nvd79KVJeXxEVuoouvsdFT78EIIEIc6QXK6zBVxxVZUSDssye7ce8TdGAoJ_0HUaCmJmk9YKrCmJmk9YKrjsu841Pb_nV5WWdQuLsKyMMeVdMs-UeVqWdAklrILYG7DR8OJMddK6T3t-hojuv78I9CzATsS03CjB0GnSxq5KnMgFaK0ajG6Q2t9g8y59ldXiliXtfzgKgGT2TQ1hYGjFRaJNJXE07-1FJ5NBN4S2_id41FrSAGBSWv6xFtd40nGod44WCy1qfCvxcQg259ld4094wIq8alIl-pEwDkQg4fd44E4_zavE6y0wmd45yszQ3h0o9_0QgdQB0yq87qNaVUvZzpEVpdU8B3tNGk0sti>


________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
Philippe Leuba
2014-05-21 07:01:23 UTC
Permalink
Hi Matt,

Thanks for your answer.

Unfortunately I already have tried to implement a replacement for ip::tcp class but without success because this class (Protocol) is used also for the resolve function call and the SOCK_CLOEXEC is not supported in this context.

I have too taken a look at socket_ops and reactive_socket_service but did not find an easy way to change the behavior without modifying the source code of boost.

The best way would be for Asio authors to support this flag.

Philippe Leuba

> On 21 mai 2014, at 00:38, "Gruenke,Matt" <***@Tycoint.com> wrote:
>
> fork() + exec() is necessary to spawn another program, on UNIX-like systems. First, you fork(), which duplicates the memory image of the parent process (and increases the refcount on things like file descriptors and sockets). Then, the child process calls exec(), which replaces its memory image with that of a new program and executes it. If the child process is short-lived, then the extra refcounts on the file descriptors should be pretty harmless. But, if it’s long-lived, then I can see how they could be problematic.
>
> I’m just not knowledgeable enough of ASIO’s architecture to answer it off-hand, though I expect it probably has the requisite flexibility. I’d track down how your sockets are getting created, then follow where the flags are coming from. It seems to me (and I’m unfortunately looking at a slightly outdated version) that you want to modify ip::tcp::type(). Or, perhaps subclass from it, override that function, and instantiate your sockets with your derived type.
>
> Even if that works, it’s not necessarily the best way to do it. Socket creation happens in detail::socket_ops. detail::reactive_socket_service<typename Protocol, typename Reactor> is what calls that. If you follow the call-chain up, you might find a better place to substitute a type, in order to perform the desired customization.
>
>
> Matt
>
Yuri Timenkov
2014-05-24 12:13:14 UTC
Permalink
Hi,

First of all, fork() and CLOEXEC are not portable (work only on POSIX systems) that's why ASIO doesn't have it.

I would recommend setting CLOEXEC afterwards, with something like:

fcntl(mysock.native_handle(), F_SETFD, FD_CLOEXEC);

Which should be equivalent to passing SOCK_CLOEXEC to open().

Regards,
Yuri
From: ***@swissonline.ch
Date: Tue, 20 May 2014 21:27:26 +0200
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec

Hi,
For what I have understood, the SOCK_CLOEXEC flag is especially intended to set the close-on-exec flag atomically at socket creation time: socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP).
But how to do this with Asio?

Philippe Leuba
On 20 mai 2014, at 20:33, "Gruenke,Matt" <***@Tycoint.com> wrote:









Race conditions at what level? If your fork/exec is not synchronized with your socket creation & configuration, then there’s a race condition even if you set
it immediately after opening it.


Matt




From: Philippe Leuba [mailto:***@swissonline.ch]


Sent: May 20, 2014 11:25

To: asio-***@lists.sourceforge.net

Subject: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec




Hi,





How can we prevent Asio TCP socket to be inherited by child process when using fork/exec. Normally this can be achieved by adding the SOCK_CLOEXEC flag at socket creation time.





Adding the O_CLOEXEC flag later is not really a solution due to potential race conditions.





Creating the socket outside of boost and assigning it to the boost::ip::tcp::socket neither because async_connect will close it and open a new one.





Any others ideas?



Philippe Leuba







This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect
of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.




------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio
Philippe Leuba
2014-05-25 13:59:59 UTC
Permalink
Hi Yuri,

I agree that SOCK_CLOEXEC is Posix only, but Asio has some file specific to Posix, like epoll_reactor where SOCK_CLOEXEC is used for epoll_create and timers_create.

Setting CLOEXEC afterwards can cause race condition if the fork is executed between socket creation and fnctl.

Regards

Philippe Leuba

> On 24 mai 2014, at 14:13, Yuri Timenkov <***@timenkov.ru> wrote:
>
> Hi,
>
> First of all, fork() and CLOEXEC are not portable (work only on POSIX systems) that's why ASIO doesn't have it.
>
> I would recommend setting CLOEXEC afterwards, with something like:
>
> fcntl(mysock.native_handle(), F_SETFD, FD_CLOEXEC);
>
> Which should be equivalent to passing SOCK_CLOEXEC to open().
>
> Regards,
> Yuri
>
>
> From: ***@swissonline.ch
> Date: Tue, 20 May 2014 21:27:26 +0200
> To: asio-***@lists.sourceforge.net
> Subject: Re: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec
>
> Hi,
>
> For what I have understood, the SOCK_CLOEXEC flag is especially intended to set the close-on-exec flag atomically at socket creation time: socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP).
>
> But how to do this with Asio?
>
> Philippe Leuba
>
> On 20 mai 2014, at 20:33, "Gruenke,Matt" <***@Tycoint.com> wrote:
>
> Race conditions at what level? If your fork/exec is not synchronized with your socket creation & configuration, then there’s a race condition even if you set it immediately after opening it.
>
>
>
>
>
> Matt
>
>
>
>
>
> From: Philippe Leuba [mailto:***@swissonline.ch]
> Sent: May 20, 2014 11:25
> To: asio-***@lists.sourceforge.net
> Subject: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec
>
>
>
> Hi,
>
>
>
> How can we prevent Asio TCP socket to be inherited by child process when using fork/exec. Normally this can be achieved by adding the SOCK_CLOEXEC flag at socket creation time.
>
>
>
> Adding the O_CLOEXEC flag later is not really a solution due to potential race conditions.
>
>
>
> Creating the socket outside of boost and assigning it to the boost::ip::tcp::socket neither because async_connect will close it and open a new one.
>
>
>
> Any others ideas?
>
> Philippe Leuba
>
>
>
> This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>
> ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs
> _______________________________________________ asio-users mailing list asio-***@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/asio-users _______________________________________________ Using Asio? List your project at http://think-async.com/Asio/WhoIsUsingAsio
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
Roger Austin (Australia)
2014-05-25 22:46:17 UTC
Permalink
Hi Philippe,

There is a similar issue on Windows when threads create child processes that inherit handles. Recent versions of Windows allow WSA_FLAG_NO_HANDLE_INHERIT to be set at socket creation to avoid this. I think it would be useful for asio to provide a portable no-inherit option with suitable implementations on POSIX and Windows systems.

A workaround would be to serialize all socket creation, either via a native synchronisation method or through an asio strand, and set the appropriate flag on the handle/FD after creation.

Regards,
Roger Austin

From: Philippe Leuba [mailto:***@swissonline.ch]
Sent: Monday, 26 May 2014 12:00 AM
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec

Hi Yuri,

I agree that SOCK_CLOEXEC is Posix only, but Asio has some file specific to Posix, like epoll_reactor where SOCK_CLOEXEC is used for epoll_create and timers_create.

Setting CLOEXEC afterwards can cause race condition if the fork is executed between socket creation and fnctl.

Regards

Philippe Leuba

On 24 mai 2014, at 14:13, Yuri Timenkov <***@timenkov.ru<mailto:***@timenkov.ru>> wrote:
Hi,

First of all, fork() and CLOEXEC are not portable (work only on POSIX systems) that's why ASIO doesn't have it.

I would recommend setting CLOEXEC afterwards, with something like:

fcntl(mysock.native_handle(), F_SETFD, FD_CLOEXEC);

Which should be equivalent to passing SOCK_CLOEXEC to open().

Regards,
Yuri

________________________________
From: ***@swissonline.ch<mailto:***@swissonline.ch>
Date: Tue, 20 May 2014 21:27:26 +0200
To: asio-***@lists.sourceforge.net<mailto:asio-***@lists.sourceforge.net>
Subject: Re: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec
Hi,

For what I have understood, the SOCK_CLOEXEC flag is especially intended to set the close-on-exec flag atomically at socket creation time: socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP).

But how to do this with Asio?

Philippe Leuba

On 20 mai 2014, at 20:33, "Gruenke,Matt" <***@Tycoint.com<mailto:***@Tycoint.com>> wrote:

Race conditions at what level? If your fork/exec is not synchronized with your socket creation & configuration, then there’s a race condition even if you set it immediately after opening it.





Matt





From: Philippe Leuba [mailto:***@swissonline.ch]
Sent: May 20, 2014 11:25
To: asio-***@lists.sourceforge.net<mailto:asio-***@lists.sourceforge.net>
Subject: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec



Hi,



How can we prevent Asio TCP socket to be inherited by child process when using fork/exec. Normally this can be achieved by adding the SOCK_CLOEXEC flag at socket creation time.



Adding the O_CLOEXEC flag later is not really a solution due to potential race conditions.



Creating the socket outside of boost and assigning it to the boost::ip::tcp::socket neither because async_connect will close it and open a new one.



Any others ideas?

Philippe Leuba

________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net<mailto:asio-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs
_______________________________________________ asio-users mailing list asio-***@lists.sourceforge.net<mailto:asio-***@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/asio-users _______________________________________________ Using Asio? List your project at http://think-async.com/Asio/WhoIsUsingAsio
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net<mailto:asio-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio
Jeff Koftinoff
2014-05-25 23:15:22 UTC
Permalink
Hi Guys

Perhaps it would be a good idea to modify ASIO to allow for specialization of the socket creation or initial socket flags. It could be as simple as an optional function pointer, virtual method, or functor that could be chosen at socket creation time via a template parameter.

Regards,
Jeff

On May 25, 2014, at 15:46, Roger Austin (Australia) <***@innovyze.com> wrote:

> Hi Philippe,
>
> There is a similar issue on Windows when threads create child processes that inherit handles. Recent versions of Windows allow WSA_FLAG_NO_HANDLE_INHERIT to be set at socket creation to avoid this. I think it would be useful for asio to provide a portable no-inherit option with suitable implementations on POSIX and Windows systems.
>
> A workaround would be to serialize all socket creation, either via a native synchronisation method or through an asio strand, and set the appropriate flag on the handle/FD after creation.
>
> Regards,
> Roger Austin
>
> From: Philippe Leuba [mailto:***@swissonline.ch]
> Sent: Monday, 26 May 2014 12:00 AM
> To: asio-***@lists.sourceforge.net
> Subject: Re: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec
>
> Hi Yuri,
>
> I agree that SOCK_CLOEXEC is Posix only, but Asio has some file specific to Posix, like epoll_reactor where SOCK_CLOEXEC is used for epoll_create and timers_create.
>
> Setting CLOEXEC afterwards can cause race condition if the fork is executed between socket creation and fnctl.
>
> Regards
>
> Philippe Leuba
>
> On 24 mai 2014, at 14:13, Yuri Timenkov <***@timenkov.ru> wrote:
>
> Hi,
>
> First of all, fork() and CLOEXEC are not portable (work only on POSIX systems) that's why ASIO doesn't have it.
>
> I would recommend setting CLOEXEC afterwards, with something like:
>
> fcntl(mysock.native_handle(), F_SETFD, FD_CLOEXEC);
>
> Which should be equivalent to passing SOCK_CLOEXEC to open().
>
> Regards,
> Yuri
>
>
> From: ***@swissonline.ch
> Date: Tue, 20 May 2014 21:27:26 +0200
> To: asio-***@lists.sourceforge.net
> Subject: Re: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec
>
> Hi,
>
> For what I have understood, the SOCK_CLOEXEC flag is especially intended to set the close-on-exec flag atomically at socket creation time: socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, IPPROTO_TCP).
>
> But how to do this with Asio?
>
> Philippe Leuba
>
> On 20 mai 2014, at 20:33, "Gruenke,Matt" <***@Tycoint.com> wrote:
>
> Race conditions at what level? If your fork/exec is not synchronized with your socket creation & configuration, then there’s a race condition even if you set it immediately after opening it.
>
>
>
>
>
> Matt
>
>
>
>
>
> From: Philippe Leuba [mailto:***@swissonline.ch]
> Sent: May 20, 2014 11:25
> To: asio-***@lists.sourceforge.net
> Subject: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec
>
>
>
> Hi,
>
>
>
> How can we prevent Asio TCP socket to be inherited by child process when using fork/exec. Normally this can be achieved by adding the SOCK_CLOEXEC flag at socket creation time.
>
>
>
> Adding the O_CLOEXEC flag later is not really a solution due to potential race conditions.
>
>
>
> Creating the socket outside of boost and assigning it to the boost::ip::tcp::socket neither because async_connect will close it and open a new one.
>
>
>
> Any others ideas?
>
> Philippe Leuba
>
>
>
> This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
>
> ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs
> _______________________________________________ asio-users mailing list asio-***@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/asio-users _______________________________________________ Using Asio? List your project at http://think-async.com/Asio/WhoIsUsingAsio
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs_______________________________________________
> asio-users mailing list
> asio-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/asio-users
> _______________________________________________
> Using Asio? List your project at
> http://think-async.com/Asio/WhoIsUsingAsio
Gruenke,Matt
2014-05-26 01:28:17 UTC
Permalink
For global customization of operations like socket creation, there's already a sufficient abstraction - detail::socket_ops. This is currently a namespace. But, if it were a class with static member functions, one could supply a custom socket_ops (which could even be derived from the default one, to avoid needless duplication) as another template parameter. Or perhaps the default socket_ops could take a set of socket creation flags as a template parameter.

IMO, socket_ops it seems like the right level for the customization, since you want to affect all sockets. It's not specific to just one protocol or service.


Matt


From: Jeff Koftinoff
Sent: Sunday, May 25, 2014 7:15 PM
To: asio-***@lists.sourceforge.net
Subject: Re: [asio-users] How to prevent Asio TCP socket to be inherited by child when using fork/exec

Hi Guys

Perhaps it would be a good idea to modify ASIO to allow for specialization of the socket creation or initial socket flags. It could be as simple as an optional function pointer, virtual method, or functor that could be chosen at socket creation time via a template parameter.

Regards,
Jeff


________________________________

This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.
Loading...