These are chat archives for vu3rdd/functorrent

5th
Aug 2015
Divam
@dfordivam
Aug 05 2015 06:20
I did not understand this "Issue with prev solution: pkill will corrupt the file. So will a bad exception or something we cant anticipate today"
This message was deleted
Current solution: Make threads kill -safe. Let them be killed at any time and let it manage cleanup internally.
We should not make things 'kill -safe', with kill it should actually get killed. We should only trap things like SIGINT, etc.
One thing I can think of now, is to do the same thing we did for logging for writing files too. Just like we have a logging thread, can we have a disk writer too?
Logging thread is not killed it is given the stop signal synchronously. And we will have to do this with all other threads which might be involved in Disk IO or which own some shared resources.
Jaseem Abid
@jaseemabid
Aug 05 2015 12:26
This needs more learning.
Ramakrishnan Muthukrishnan
@vu3rdd
Aug 05 2015 13:32
@jaseemabid Unfortunately I am busy till end of Aug. Too many things going on at work at the moment.
logging in after a while, lots to scroll up and read.
Divam
@dfordivam
Aug 05 2015 13:48
The tool on which I work even has to traps the Segmentation fault from the OS and handle it.
One of the things which we do is: We put a limit to the stack size of executable and if there is segmentation fault due to stack overflow, we increase the stack size and try to identify the issue in the executable which caused the stack overflow
another strange thing which we do is: to do null checking instead of doing "CMP 0 RAX JNE 0xaddress" we directly do "copy RAX (RAX)", this also causes segmentation fault, so we trap this and flag a Null Object access error.
Jaseem Abid
@jaseemabid
Aug 05 2015 18:21
Hmm. Not an area I'm very strong at.