On Wed, 23 May 2012, Hefty, Sean wrote:
> netperf
> - By default netserver forks a child process for each netperf client. As
> rsockets
> doesn't support fork() yet, this doesn't work.
Btw, fork() is unlikely to work anytime soon, if ever...
rsockets() is a perfect as a wrapper providing Sockets over RDMA, and so is
very attractive. Really nice work.
But to map standard networking applications to rsockets we will run into the
above problem i.e. fork() will not work. It would be very useful to
allow for the standard networking paradigm of: bind()->listen()->accept()-
->fork(), and then the server goes back to accept(). That would allow us to
use rsockets transparently with existing applications.
Is it possible to support fork() for this standard model where the parent
closes its copy of the newly created socket and goes back to waiting on the
original socket in accept, and the child continues with the newly created
socket?
Have you considered some other options to make this happen?
Could we skip creating the endpoint in raccept(), but actually create the
new endpoint during the frist receive or send? This would then allow the
fork() to occur without the complications with the pinned data.
thoughts?
thanks
Vivek
