Hi Nausca,
Could you take a look at:
https://github.com/dmtcp/dmtcp/pull/289
[dmtcp] Added support for non-blocking connect. (#289)
and see if this satisfies your requirements? If you have a github account,
you can also help to review the pull request. The commands to download
the code and try it out are:
git clone https://github.com/karya0/dmtcp.git dmtcp-karya0
git checkout connect-in-progress
cd dmtcp-karya0
git checkout connect-in-progress
Thanks,
- Gene
----- Original Message -----
From: "Nausca Hsu"
Sent: Monday, January 18, 2016 4:58:27 AM
Subject: Re: [Dmtcp-forum] the connect hack in ipc plugin
Hi Gene,
Yes, this is my concern.
It actually happens at our software where a license library use its own
socket error handling.
Another concern is, the 15 seconds select change the behavior of
non-blocking connect call to 15 seconds blocking.
Thanks.
Nausac.
On 2016/1/16 07:27, "Gene Cooperman" <g...@ccs.neu.edu> wrote:
>Hi Nausca,
> Sorry for the slow response. I'll summarize your e-mail for
>Kapil, who is our specialist in this area.
>
>Kapil,
> You had implemented the ipc plugin. Nausca is proposing an
>alternative strategy for registering new socket file descriptors
>in our SocketConnList.:
> Register the socket ID directly in the select/poll function call?
> 1. Every time a user calls select, DMTCP can check if the selected id
> is already a registered connection within DMTCP.
> 2. If it wasn't previously registered, then register it within
> the select/poll function call.
>
>The motivation follows:
> There is a DMTCP wrapper for connect():
> src/plugin/ipc/socket/socketwrappers.cpp:connect(sockfdi, ...)
>In that wrapper, if real_connect() fails, then it tries again
>for 15 seconds:by calling select([sockfd]). If select()
>succeeds, then getsockopt() is tried. If that succeeds,
>then sockfd is added to the SocketConnList.
> Otherwise, we assume that the user tried to connect to a
>non-existent socket, and we don't register sockfd.
> The problem with this is that the user may have their
>own backup strategy using poll() or select(). So, DMTCP may
>fail to register sockfd(), and yet later, the user's call to
>select() may discover a valid sockfd.
>
>For this reason, Nausca is proposing to add logic into the DMTCP
>wrapper around select() (and poll()) so that if the user discovers
>a valid sockfd, DMTCP will also see this, and DMTCP will register
>the sockfd in the SocketConnList.
>
>Nausca,
> Did I summarize the issue correctly?
>Best,
>- Gene
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Dmtcp-forum mailing list
Dmtcp-forum@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dmtcp-forum
