Re: RE : [sysapps/raw socket api]: New version to be reviewed at Madrid F2F-meeting

On Apr 8, 2013 4:56 PM, "Ke-Fong Lin" <ke-fong.lin@4d.com> wrote:
>
> Hi Claes,
>
> >> It's just a matter that browser  (or any non-privileged application)
> >> won't be able to instantiate UDPSocket, TCPSocket, and TCPServerSocket
> >> objects. But perhaps it's better to live that to security experts.
> >[Claes] Yes, let us discuss in Madrid.
>
> John Lyle has sent an interesting email about that, I hope he's there at
Madrid.
>
> >[Claes] My thought was that the developer had to create a new socket if
multicast wasn't going to be used more. However, if we have an explicit
joinMulticastGroup() then I guess that we should have leaveMulticastGroup()
as well.
> >
> >By the way, I haven't specified a "close()" or destroy() method for UDP
Sockets as there is no connection setup. A developer can always stop
listening to incoming data by calling suspend(). Then JavaScript garbage
collection will handle removal of unused sockets objects. Do you think that
this is sufficient? Or do we need a destroy() or similar method for UDP
Sockets?
>
> I'd rather think it's better to have an explicit way to do so. For a UDP
socket, destroy() would be the equivalent of Berkeley socket's
close(socket_descriptor_id).
> Garbage collector runs "when it wants", it may be a long time before it
actually does the collection, and OS socket descriptors are limited in
number (that's a huge a number, but still limited).
> Also for the developer, that can be tricky, for WebSocket :
http://www.w3.org/TR/2009/WD-websockets-20091222/#garbage-collection
> Garbage collection is not done if there is at least a registered  event
listener. So all listeners would have to be unregistered and then the
socket object must not be referenced anymore.
> That's easy to forget or miss.
> With a close(), we can leak a JavaScript object but make sure we don't
leak a process wide resource.

Indeed. A general rule of thumb in garbage-collected languages is "don't
rely on GC to recover expensive resources". I.e. if an object represents an
"expensive" resource, then don't rely on that object getting GCed in order
to free that resource.

The reason for this is at least two-fold. First off it's quite common to
"leak" objects even in GCed languages. This is not a traditional leak in
the sense that the objects are still reachable. However its very easy to
have bugs which result in references to objects that will never again be
used.

The other reason is that GC can run quite rarely. GC can be very expensive
so implementations optimize for doing it as little as possible. And with
generational GCs an object can stay around for very long periods of time
even if no references to it exist and even if plenty of other garbage is
being created. Even modern GC implementations generally treat all objects
as equal and so doesn't realize that freeing a particular object can free a
lot of resources.

What counts as "expensive" above is of course a judgment call, bit I would
argue that an open socket is an expensive resource.

/ Jonas