Re: copy constructor for sockets

[Simon Wright <simon@pushface.org>]

"Andrew Carroll" <andrew@carroll-tech.net> writes:

> All the "accepting" task does is initialize sockets and create new
> tasks.  Well, it will do other things but right now I am just
> experimenting.  Your select() or poll() idea is beautiful!  Because
> then, when an accept would occur, I can have the tasks ('A' or 'B')
> handle the whole "session".  Question now is, how do I know which
> task to assign it to for handling?  I cannot get into the HTTP
> header before I "accept".  Hmmmm....Anyway...

I think that's a big Hmmmm :-(

The task is a thread of control, whereas you want different
behaviour. When I was designing my Embedded Web Server
(http://sourceforge.net/projects/embed-web-srvr/) I managed that by
having the Response be a tagged type, created by factory operations
registered against the .. damn, forgotten the name, the
"/projects/embed-web-srvr/" in the URL above.

> Never the less I am learning some great things.  You mentioned that
> a socket is a file descriptor (Unix) and I'm not quite sure I fully
> understand the implications of that.  I "heard" that sockets were
> designed in such a way that it would be "transparent", like working
> with files.  Does that mean I can do a seek() on a socket?  When
> people throw out the term "file descriptor" and start talking about
> "small positive integers" I draw a blank as to how those are used
> for "communication" over a network device in general.  After all,
> there are MANY small positive integers on my computer.  I'm assuming
> the file descriptor (fd) means something to the OS?  So somewhere in
> the kernel or "shell" interrupt handler there is an else if (//it is
> a small positive integer) { //must be a socket, fire-up the RS-232
> driver}?

It's going to be some higher level of abstraction in the OS than that,
after all you might be using an Ethernet LAN or a cable modem. But,
yes-ish.

> I thought a socket was an abstraction from an address?  For
> example. the address to a UART or RS-232 PIC.  A driver of which is
> written (probably a module) to control that device.  So how does a
> fd relate to that driver?  Or are you saying that somewhere in my
> /dev directory there is a directory entry for my UART?  I can just
> arbitrarily (at risk of destruction) send data to the UART through
> an entry in the /dev directory?

_Very_ roughly, on Unix (POSIX) systems, the fd looks to you, the
user, as a small positive integer, but inside the OS it's an index
into a whole set of data structures. These might hold pointers to the
actual operations to perform read(), write(), sendTo() etc + pointers
to the actual connected channel (console i/o for fd 0, some networking
stack for your server).

But you're right, it is an abstraction; this small positive integer is
not something you want to go adding 1 to!

-- 
Simon Wright                               100% Ada, no bugs.