HI, It is a touch unclear what you mean by deleting the file and on which OS you are using.
On Linux and similar OSes the rm command just calls the unlink system call. This removes the file from the directory and if the link count is now 0 then the file is removed from disk. But this last part happens only if the file is not open. If it open you get a situation where it is still on disk but not visible in any directory. As long as the process does not close the file then all is good. You can write and read to the file with no problems. But when the file is closed then the file will disappear from disk. More than once in my life there has been the "where did all the disk space go?" conversation that has resulted in a multi megabyte, multi gigabyte or now multi terabyte file being found and deleted. Without figuring out that it was open and therefore won't go away until some process is killed as well. Now none of the above could apply to Racket. One would need to know the gory details of how file writing is implemented. But this would explain what you see. cheers bruce On 2021-12-19T18:08:13.000+01:00, Sage Gerard <s...@sagegerard.com> wrote: > If I understand this correctly, there's a difference between > deleting a _reference_ to 50 GB (like an inode), and actually > writing 50 GB. > > When you write to an output port, you are writing to a buffer in > memory. This prevents the slow downs you've witnessed, because > storage mediums are comparably slow. "Flushing" with (flush-output) > or plumbers on port closure actually sends bytes outside of the > process. > > I wouldn't try using the same port after deleting a file. If Racket > and the operating system initially agreed on a file descriptor that > is now invalid, then you'll need to address that by opening a new > port. > > Note that I don't Racket's implementation details here. I'm > recalling what I've seen happen across languages. > > On 12/19/21 11:50 AM, Jacob Jozef wrote: > >> Hi >> >> >> >> I start a thread printing a file. When the file will be very long >> (say 50 GB) the thread takes too much time and I kill it when it >> takes more time than I want to permit. Outside the thread I clean >> up. Closing the output-port before deleting the file takes much >> time. But to my surprise I can delete the file before closing the >> port, which hardly takes time. >> >> Nice. >> >> Is this intended behaviour? >> >> After deleting the file, the port remains open, but writing to it >> does nothing. Correct? >> >> >> >> Thanks, Jos >> >> >> >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Racket Users" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to racket-users+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> >>https://groups.google.com/d/msgid/racket-users/EEC04679-E526-4215-B4DE-502B5B10567A%40hxcore.ol >> >>[https://groups.google.com/d/msgid/racket-users/EEC04679-E526-4215-B4DE-502B5B10567A%40hxcore.ol?utm_medium=email&utm_source=footer]. > > -- > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > >https://groups.google.com/d/msgid/racket-users/076c95f8-1d49-4294-9df8-73b1b39b1f01%40sagegerard.com > >[https://groups.google.com/d/msgid/racket-users/076c95f8-1d49-4294-9df8-73b1b39b1f01%40sagegerard.com?utm_medium=email&utm_source=footer]. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/59d8fba7f9183f7acfabd8f7689d032b%40mail.infomaniak.com.
