Thanks George,

I got it now and after some experimenting have seen what you describe.

Jos

 

PS,

I do close the port after killing the thread and deleting the file. I came across this because I have an object that is written on about two pages with sharing enabled, but takes more than GBs to write without sharing enabled. I included my thread as an example. It is in file The-Little-LISPer.rkt on joskoot/The-Little-LISPer (github.com). The object is the result of having a meta-recursive interpreter interpret its own source code. Following the style of the book by Danial P. Friedman and Mathias Felleisen, non primitive functions are represented by symbolic expressions. In the same GitHub is file interpreter.rkt which represents functions by procedures. The latter writes “#<procedure>” when interpreting its own source code. (When you want to run my code, you may have to install my package test, which also is in my GitHub repositories (documentation included)).

 

Jos

 

 

From: George Neuner
Sent: lunes, 20 de diciembre de 2021 5:37
To: racket-users@googlegroups.com
Subject: [racket-users] Re: Surprising but convenient

 

On Sun, 19 Dec 2021 17:50:11 +0100, Jacob Jozef

<jos.k...@gmail.com> wrote:

 

>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.

 

It will take less time to stop the thread if you work line by line, or

in small(ish) groups of lines, and flush the output port each time you

go back for more input.

 

As for deleting the file, all you have done is remove the directory

entry ... the file itself won't go away until the last open handle on

it is closed.  That particular behavior /is the same/ in Windows and

Unix/Linux.

 

 

>After deleting the file, the port remains open, but writing to it does

>nothing. Correct?

 

No. Your program still has an open handle to the file and it is still

reading from it.  Only the file's directory entry is gone.

 

You need to close the open file handle in your program in order to

truly delete the file.  Depending on your code, simply killing the

thread may not do that.

 

 

>Thanks, Jos

 

Hope this helps,

George

 

--

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/2h10sgt81h7nim2ps3dfak2te00m3724hv%404ax.com.

 

--
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/9F26A2E2-6547-4611-9961-0C696E5ACDC7%40hxcore.ol.

Reply via email to