In another thread, James Sentman said:
Im fairly sure that file access is blocking for all threads until its 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:
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
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))
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.