#17 connection::on_close

[Steven Van Ingelgem]

Hi,

It would be really convenient to subclass a dlib::connection with for example a virtual void on_close().

This would be called at the time the connection is being dropped.

Why is this convenient for me?

I am creating an 'always-on' connection. And I need to see if the connection is active or not. Ofcourse I can check the output from read/write, but it would be nice if I just got called in those instances the connection dropped so I can do some other actions.

At the moment I just check if read/write == SHUTDOWN, and then call on_close(), but it would be nice to have it called automagically ;)

Greetz,
Steven

[Davis]

Logged In: YES
user_id=1166290
Originator: NO

I don't think this sort of indirection is a good idea in the long run. You are basically talking about replacing something that is conceptually really simple (the client getting a return code from read()) with some more complex event driven thing. There are a lot of issues you have to think about to implement this.

Subclassing dlib::connection won't work because the constructor is private (long story, basically I think having it private makes it harder for people to screw up when using threads and sockets together). So the other option would be to have some kind of connection.set_on_close_handler() thing. People would call that to set the function which gets called when the connection ends. Now you have to decide what thread calls that callback and when? Does every thread that calls any function on a connection object that fails call the handler? Or is some other thread going to get spawned to do it. This matters because if your handler does something that blocks it will block the rest of your stuff if it isn't running in an independent thread. But putting it in an independent thread makes people have to use things like mutexes and signalers to do anything now.

Now I'm not saying that it would be hard to implement. Just that all these things are considerations and most importantly they have to be understood by the people who will use it. If they don't understand all these issues related to the things I just mentioned they will have a problem and their programs will mysteriously crash or not work. And I guarantee you people won't understand because they will not read the documentation (which will be somewhat complex since it has to explain all this) or they will skim it really fast and make incorrect assumptions. We all do this, even me on occasion :)

The way it is now, just returning an error code, is really simple and obvious to everyone (relatively speaking). So the chances of it being used wrong and resulting in really mystifying behavior are low I think.

Sorry to go on and on but I like to keep things simple and didn't just want to say request denied without any explination :)

Cheers,
Davis