What happens if an application is closed while a thread of ThreadPool is writing a file?

Question

Suppose you use a ThreadPool to perform some operations and assume that each operation writes on a file. All threads of ThreadPool are background threads, so they will be terminated when closing the application. What happens if the application is closed while a thread of ThreadPool is writing a file to disk?

Sanalda

It would close the filehandle to the file and stop writing to it, probably ending up in corrupted state of the file. Have you tried doing that? – Outworn

I should verify what happens by writing a big file. – Sanalda

The result most likely varies with the used FileSystem. FAT will Show other results than NTFS. – Wellknit

In general, if you find yourself needing answers to questions like these (which is useful in and of itself, don't get me wrong) that's probably a sign you should change your design to something that's obviously correct, rather than relying on the good graces of the framework. In other words, if you have to make sure the operations finish, don't use background threads -- or assume your application can be closed at any time and leave its files corrupted, and handle this scenario on startup accordingly. – Efthim

Answer 1

Operating system will close the file handle as the part of terminating the process.

• Any pending asynchronous I/O will be canceled
• Any data in the write buffer which isn't flushed gets lost

Matson

Answer 2

Read the MSDN article on Foreground and Background threads

ThreadPool threads are background threads. From the article:

When the runtime stops a background thread because the process is shutting down, no exception is thrown in the thread.

The thread simply stops. It executes one instruction, and never executes the next. The FileStream will be closed as part of the CLR clearing up.

Enosis

CLR will not close the files. It is the underlying operating system which does that. – Matson

If a process gracefully terminates, then finalizers will be called: see blog.stephencleary.com/2009/08/finalizers-at-process-exit.html. FileStream's finalizer closes the underlying file handle. – Enosis

Finalizers will be called as the part of garbage collection only when the instance is unreachable. How come FileStream go unreachable when ThreadPool threading is writing with it? – Matson

A simple demo app indicates that the FileStream is indeed closed by the CLR before termination. I kick off a new work item on the ThreadPool, which opens a file and waits a second, and has a finalizer which attempts to close the file. The application is terminated within that second. Attempting to close the file in that finalizer causes an ObjectDisposedException, indicating that the CLR's already disposed the FileStream object. Or am I misinterpreting something? – Enosis

I've just checked too. I tested it with static field. finalizer gets called in Winforms app but when closing the console application using the close button it doesn't gets called. Your answer also seems to be right. +1 – Matson

Answer 3

You can easily try this situation by calling Environment.Exit(0) and Environment.Exit(1) method (successfull exit and exit with error). I think that all the handles for the file will be removed, and the only data already written to the disk will remain, without flushing the buffers.

Althrough, the file could became unaccessible with some strange error like The file is being used by another process or something in case of error exiting the process.

Decorative

The argument you pass to .Exit() doesn't matter; in both cases the application terminates gracefully (meaning finally-blocks and finalizers will run). While you're experimenting, try Environment.FailFast(), as that, unlike Exit(), is not a graceful termination and will bypass finalizers. Note that flushing buffers is something that could be done in a finalizer, but the BCL classes typically don't (which is a shame, since the OS closes handles anyway and that's the only added value the finalizer would have). – Efthim