From sig handler just call safe functions.

As long as you don't do what R.. user says in the comments below the answer you must
use only safe functions.

http://stackoverflow.com/questions/8833394/can-exit-fail-to-terminate-process/8833602#8833602

do not repeat close when EINTR

See: Returning EINTR from close() - http://lwn.net/Articles/576478/
     Linus Torvalds - http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-09/3000.html

Comments about inherited signal dispositions.

fixed error in create_args function

fixed #1. Using execvp instead of system.

Working on issues: #1 #3.

No more shared memory, execv/execl solution.
UTF-8 always between client and server (avoiding issues with strtok)

Avoid SIGPIPE and polite kill child process.

SIGPIPE when using send method and remote side closed connection.

Portable alternatives: sighandler for SIGPIPE or block/ignore SIGPIPE. In some situations we
may not ignore SIGPIPE (if we are writing some API we may not just swallow SIGPIPE) because of that
depending o the situation we could ignore or block SIGPIPE.
There is SIGPIPE JUST when using send/write (no with read/recv) and remote side closed connection.

Wait for client to close connection: improvement (I hope)

Avoid TIME_WAIT state, server side: wait for client to close connection.

See:
http://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable
http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html
http://stackoverflow.com/questions/3757289/tcp-option-so-linger-zero-when-its-required

By the way, never use SO_LINGER. The application level protocol should be implemented
in such way that allows the client side to find out when server side ended up sending
data and in this way the client is able to close the connectiond and server side does not
finish with sockets in TIME_WAIT state.

I do not think daemonize function is needed.

Remove it once I get time and just use setsid function.

Doubts about setsid. TODO some day.

How to launch daemon (improvement)

Multiple minor changes:

1. Return -1 from main function as error code.
2. Close useless file descriptors in child process.
3. Improving some comments and error messages.
4. Errors from poll function.

EXIT_SUCCESS & EXIT_FAILURE constants / _exit

About _exit: I do not think I really need to use _exit but anyway it seems to me like it does not hurt me so... Let's do it in the right way!!!

From: http://www.unixguide.net/unix/programming/1.1.3.shtml / http://stupefydeveloper.blogspot.com.es/2009/01/c-to-exit-or-to-exit.html

There are a few differences between exit() and _exit()
that become significant when fork(), and especially
vfork(), is used.

The basic difference between exit() and _exit() is that
the former performs clean-up related to user-mode constructs in the
library, and calls user-supplied cleanup functions, whereas the latter
performs only the kernel cleanup for the process.

In the child branch of a fork(), it is normally incorrect to use
exit(), because that can lead to stdio buffers being flushed
twice, and temporary files being unexpectedly removed. In C++ code the
situation is worse, because destructors for static objects may be run
incorrectly. (There are some unusual cases, like daemons, where the
parent should call _exit() rather than the child; the
basic rule, applicable in the overwhelming majority of cases, is that
exit() should be called only once for each entry into
main.)

In the child branch of a vfork(), the use of exit() is
even more dangerous, since it will affect the state of the parent
process.

Fixed error in sizeof for unsigned char.

Right type for storing return code from fork

Unblock SIGCHLD signal in child process.

Exit from custom SIGINT handler. The right way.

As seen on: http://www.cons.org/cracauer/sigint.html

Blocking SIGCHLD with pthread_sigmask

Improving the set signal_handler code

Using right type for data bytes:

* char:
It is the type that makes up C strings like "abcde"
It also works out as a number value, but it is unspecified whether that value is treated as signed or unsigned. Beware character comparisons through inequalities - although if you limit yourself to ASCII (0-127) you're just about safe.

* signed char:
Gives you at least the -128 to 127 range.

* unsigned char:
Gives you at least the 0 to 255 range.

There is this warning: pointer targets in passing argument 1 of ‘system’ differ in signedness
I guess, it does not hurt me.

Check shell has not set up an initial action

The daemon process sends to the Java client in case of any error the value -1.
In this way, the Java client's code always will receive a return status from the daemon process
and just in case of any error it receives an error status.

XML parser removed. We begin to use my own protocol.
Next step: Java NIO for the Java client code.

Comment with questions about packing, serializing and alginment

More steps in my JavaTCPForkDaemon.
I must concatenate the protocold header and the payload.
Should I use writev?

Some code improvements.
First steps with the new way to send the stdout, stderr and return status code
to the client program. Thinking about a typedef struct, but I am wasting bytes
using this way. Is it worth wasting bytes?

Removing some useless white spaces....
Sorry for this commit...

Nothing important,
just another english grammar mistake in javafor.c

Clening up code, and errors control.
TODO: stop using XML, I am going to use my own protocol for
sending stdout, stderr and return status code in this way
I will avoid the shared memory and the code complexity.
Besides it should reduce the memory usage.
Next weekend more.

New nice method to read data from socket.
Some useless comments just left to remind me what I am going to do the next week.
Just is left to improve the fork_system function (IMHO)

Some minor changes in REAME files

Grammar mistake in README file :/

Removing executable file

first commit