Is file I/O blocking?

In another thread, James Sentman said:

[quote]
I’m fairly sure that file access is blocking for all threads until it’s done[/quote]

Is this true?

If it is, might reading file data in through a Shell program’s stdOut be the answer? If so, does the Shell need to be in asynchronous mode or will threads support Shell.Result returns in a non-blocking manner?

Definitely true. A common workaround is to read or write in chunks.

If needed, I could provide functions for MBS Plugins to do asynchronous read/write or thread friendly read/write.

I logged an enhancement for non-blocking disk IO last year:
feedback://showreport?report_id=52196

what do i need to do to accomplish that??

Cough… a nonblocking FileListMBS would be really helpful. I sometimes need to iterate over 100k files. While FileListMBS is very fast it shows the beloved spinning pizza.

I can add a yield parameter to FileListMBS class.

Here’s how I do it:

Dim Stream As BinaryStream = BinaryStream.Create(File, True) Dim CurrentThread As Thread = App.CurrentThread If CurrentThread = Nil Then Stream.Write(Contents) Else Const ChunkSize = 1024000 For I As Integer = 0 To Contents.Size - 1 Step ChunkSize Dim Chunk As String = Contents.StringValue(I, Min(ChunkSize, Contents.Size - I)) Stream.Write(Chunk) CurrentThread.Sleep(10) Next End If Stream.Close

In this case Contents is a MemoryBlock. If called on the main thread, it just writes the entire contents at once, since adding a loop won’t help you in any way and there’s no thread to sleep. But if called on a thread, it writes in 1MB chunks and rests for a moment.

Almost seems that a “ThreadedWriter” which is just a subclassed thread that writes your file would be useful

This kind of solution only takes you so far though. We have a customer who’s NAS is extremely saturated and performing a simple action on a FolderItem can block for several seconds. Luckily the project isn’t too complicated so we have replaced most of our IO code with calls into the Win32 API.
Real non-blocking IO / pre-emptive threads / a more efficient FolderItem would really help in a lot of scenarios.