It is IMHO very important to have a constructor in std.socket.Socket which takes a FILE DESCRIPTOR as an argument and makes socket out of it.

There are several reasons for this, and UNIX developers can most likely come with hundreds of possible use-cases.

I, for an instance, have encountered this problem while I was working on an upcomming FastCGI interface for D, which is ~65% done. It works when FastCGI application opens socket, and listens on it, but not when server opens a UNIX domain socket and spawns FastCGI application, for exactly the same reason why I am posting this text. Web server (lighttpd in my case) closes all file descriptor of a FastCGI application, and leaves only 0. 0 is commonly used as STDIN, but in this case it is not. It is actually a UNIX domain socket which FastCGI application has to MAKE, and listen for web-server connections. Yes, web-server is a client to the FastCGI application.

This approach is so good and effective, that some big websites are using lighttpd because it's excellent (built-in) support for FastCGI. This makes it very easy to have load balancing, because FastCGI applications can run on remote server(s) as well.

Anyway, we will soon have it, because I'll naturally release it under some open-source license, most likely BSD.

Yes, I had to subclass Socket and add this new constructor to the FastCgiSocket class, but I <b><u>really</u></b> think this is something that should be in the std.socket.Socket by default.

This is just one Phobos issue I have and would like to have improved. That was the reason I asked few days ago for a new discussion group, because I do not want to "pollute" general digitalmars.D newsgroup with Phobos related issues.

PS. I know there is already FastCGI interface for D. The only difference between my implementation and that one is that my FastCGI interface is native D, while that one is, as far as I know, a binding to libfcgi.

Kind regards

Dejan

Dejan Lekic Wrote:
> It is IMHO very important to have a constructor in std.socket.Socket which takes a FILE DESCRIPTOR as an argument and makes socket out of it.

Isn't it sufficient to have a setter method to set the handle?

Something to go with the existing getter method that returns the raw socket handle:

socket_t handle();
  Get underlying socket handle.

Once you had that you could subclass (as you have done) calling the setter in your constructor, no?

Regan

Yes, it is sufficient.

Regards

Dejan Lekic Wrote:
> Yes, it is sufficient.

In that case I reackon that's what we want added.  Both ways work but this one seems to make more sense to me.  What do you reckon?

Regan