Adding Unix file-socket capability to DMTCP

[pgrosu]

This add Unix file-socket capability for DMTCP when a network is not available.

Documentation detailing the reasoning: Checkpointing_The_Initialization_Procedure.pdf

[pgrosu]

And I did this from Dekaksi following the instructions from here: https://github.com/dmtcp/dmtcp/wiki/DMTCP-GIT-Cheatsheet :)

[pgrosu]

Hey Kapil (@karya0) regarding your question on the pre-commit formatting-check. So initially I did this on Windows and Rohan mentioned I should do it on Linux so that the style-check kicks in. So I did this on Dekaksi and never got an error, which is why I mentioned that I used the Wiki page - indicating there could be an issue with how the pre-commit hook gets triggered. Thank you for the comments, and will answer the rest later today since I have a presentation to put together quickly for the Formal Methods class, which has a 48-hour due date.

[jiajuncao]

This change seems to make Unix domain socket a special case by setting an env var. If we want TCP sockets and Unix sockets to coexist, then we might have to take care of the env var each time we create a new jalib socket, which is quite painful, in my opinion. I wonder if it is possible to extend (maybe inherit?) the current jsocket API, given the fact that the only difference between the two is the type and addr format. I haven't looked much into the code, but one possible hack would be to add an additional member, which is a hint to the constructor, default to false, telling if it is a Unix domain socket. This may not be (most likely not!) the best solution, but I think it fits more naturally to the design, as the type of the socket is an attribute of the specific socket instance.

[pgrosu]

So I documented my progress in the following document (see PDF link below) which led me to reach the current implementation. The methodology I followed was to perform dataflow analysis to understand the implementation, and then determine what were the minimal necessary-and-sufficient invariants that would keep as much of the code untouched:

Checkpointing_The_Initialization_Procedure.pdf

I'm not opposed to exploring ideas but I prefer we spec any ideas, analyze their implications and select the one for optimal integration. If that process is too long and one satisfies an immediate need in the meantime, then we can optimize to a better one later while working with something that is operational.

What do you think?

Just my $0.02, ~p

[rohgarg]

So I did this on Dekaksi and never got an error, ...

Did you use it for creating a local commit or for pushing an existing commit upstream to your fork? The pre-commit hooks trigger only when you are doing a local commit. I tried applying this patch and doing a local commit on Dekaksi, and it does trigger the pre-commit hooks. Here's what the output looks like for me:

$ git add jalib/ src/
$ git commit
jalib/jsocket.cpp:238: space before tab in indent.
+  	return ::connect(_sockfd, (const struct sockaddr *) &FILE_SOCKET_ADDR, sizeof(struct sockaddr_un)) == 0;
jalib/jsocket.cpp:256: space before tab in indent.
+  	return ::bind(_sockfd, (const struct sockaddr *) &FILE_SOCKET_ADDR, sizeof(struct sockaddr_un));
...

So perhaps it has to do with some configuration settings in your account?

[pgrosu]

Hi Rohan,

Yes of course a local commit first, as the wiki instructs. Here's a list from my Dekaksi history as to the exact steps and never got it to trigger the pre-commit hooks:

cd dmtcp/
git pull --rebase origin master
git push origin master
git branch
git checkout -b AddUnixFileSocket
cd jalib/
cp ../../../unzipped/dmtcp-file-socket/jalib/* .
cd ..
cd src/
ls
cp ../../../unzipped/dmtcp-file-socket/src/*cpp .
cp ../../../unzipped/dmtcp-file-socket/src/*c .
cp ../../../unzipped/dmtcp-file-socket/src/*h .
cd ..
git add .
git status
git remote add dmtcp-pgrosu https://github.com/pgrosu/dmtcp
git commit
git push dmtcp-pgrosu AddUnixFileSocket

`p