Profiling the memory in D

kerdemdemir kerdemdemir at gmail.com
Sat Dec 7 19:26:00 UTC 2019


On Wednesday, 4 December 2019 at 22:51:45 UTC, Steven 
Schveighoffer wrote:

I localized that the leak was actually being caused by 
websockets. I want to write down my experience because I did some 
weird stuff which seems to be working but I want to learn how it 
actually make sense and works.

I had a fancy work flow which caused by that bug 
https://github.com/vibe-d/vibe.d/issues/2169 which disallowed to 
open multiple sockets from my main process.

I solved that by lunching multiple process and using one web 
socket by one process. And communicated this process and my main 
process via zmqd.

My suggestion is; don't do that. Don't be super creative with 
current Vibe websockets. I had this unidentifable leak which took 
to much time to localize.

The bug I created around one year ago is solved now so I left 
creating processes approach and put web sockets in to a list.

Next problem I had while listening 300 websocket was I got some 
crushes within
webSocket.dataAvailableForRead() function, I am not sure if it is 
a bug or my misusage some how so I haven't created a bug yet. But 
my question to vibe forum can be seen 
https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/112309/

I solved that ( I hope ) by using something like:

if ( webSocket.waitForData(0.msecs) && 
webSocket.dataAvailableForRead() )

I know it looks so wierd to wait for 0.msecs but things seems to 
be working :/ .

The last problem I had was with closing the socket because this 
sockets are getting disconnected time to time. I need to close 
and reopen. When I call
webSocket.close() directly, after my program runs about 1 day it 
was freezing in a function called epoll while calling 
webSocket.close().

I also find another weird solution to that problem :

while ( true )
{
     auto future = vibe.core.concurrency.async( { 
socket.socket.close(); return true;} );
     vibe.core.core.sleep(100.msecs);
     if ( future.ready() )
         break;
     writeln( " Couldn't close the socket retring ");
}
sockets.remove(uniqStreamName);// BTW order of this removal 
matters if you remove
    //from your list before closing the ticket you are screwed.


Which seems to be working with 300 websockets around 2 days 
without any leak nor crush neither freeze.

As I pointed in the beginning I don't have any question or 
problems now but I am very open to feedback if you guys have any.

Erdemdem








More information about the Digitalmars-d-learn mailing list