blairmcg
commented
4 years ago The STBFiler doesn't know where the boundaries between object graphs are. One use case would be to streaming over a sequence of objects that are within the same object graph. Another use case might be the one you apparently have where there is a sequence of independent graphs that would never contain cross references between them. Therefore the filer itself cannot be responsible for deciding when to discard its state, at least not without adding some optionality. It probably makes most sense to make the state cleanup decision in your own code, either by creating a new filer for each message sent and received, or by resetting between each message on both sides. I'll update the Chat sample to work this way for illustrative purposes.
pjavier29
I have 2 applications written in Dolphin SmallTalk, version 7.1.14, communicated by socket. To send data I use the following object: (STBOutFiler on: socket writeStream) that stays alive during all communication.
To receive data I use the following object: ((STBValidatingInFiler on: socket readStream) validationBlock: [: className | true]; yourself) which also stays alive throughout the connection.
The problem is that applications can be connected for hours using the same socket and objects are being sent all the time. The STBFiler objects have writeMap and readMap attributes respectively, which record all the objects that are received or sent, which causes them to accumulate thousands of instances that are not used but are not eliminated because they are referenced by those attributes. Eventually, at some point the applications crash due to lack of memory. Shouldn't the STBFiler clean up objects that have already been sent or received? or the way i connect the apps is wrong?
Greetings and thank you very much.