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

Ok, this is very convincing :-) I will add a close() method for UDP.

Claes

Skickat från min Sony Xperia™-smartphone

Jonas Sicking <jonas@sicking.cc> skrev:


On Apr 8, 2013 4:56 PM, "Ke-Fong Lin" <ke-fong.lin@4d.com<mailto: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

Received on Tuesday, 9 April 2013 21:23:55 UTC