[Windows only] Fix annoying message Processor [info]: removing invalid read-select fileDescriptor:xindx:y

[Patrik Svestka]

This is really annoying message every time StX has to work with files on filesystem:

Processor [info]: removing invalid read-select fileDescriptor: 9 idx: 2
Processor [info]: removing invalid read-select fileDescriptor: 15 idx: 2    

The number of messages varies time to time and is totally unpredictable.

[Jan Vrany]

This happens a lot when one browses through the code, i.e., when looking at classes and method sources.

After a quick debugging, the invalid file descriptors belong to pipes, not regular files (experimentally proved by attached Q&D debugging code).

Highly likely these pipes are those created by HGCommand when executing an hg.exe to retrieve
commit info - see NewSystemBrowser >> #updatePackageInfoForClass.

---

The hypothesis is that following happens if following order (there are multiple threads involved):

1. Initially:
   • *Browser thread* runs HGCommand >> #execute, this spawns:
   • *hg command stdout reader* thread that reads and parses the output from output pipe.
   • *hg command sdferr reader* thread that reads and parses the output from error pipe.
   Reader threads may enter a read-wait, waiting for more input (thus the file goes to central select dispathing done by ProcessorScheduler)
2. hg.exe terminates.
3. Smalltalk enters the central select dispatching but since endpoint of one of these pipes is gone, we get EBADF, enter ProcessorScheduler >> #removeCorruptedFds and we get the message.
4. *Browser thread* gets scheduled, closes the pipes and all is fine.

Note, that if steps 3. and 4. executes in different order, 4. first and 3. afterwards. one gets no error message.

Now, how to prove this hypothesis? How to fix it if it's true?

[Patrik Svestka]

Testing could be, perhaps, done in a way that step 2. would be done after step 4; when the pipes are closed.

For rectification - that is more food for thought.

[Patrik Svestka]

I have just now performed a commit via St/X on Windows. When I have tried to update to working copy (hg up -r c40c9ef127f2), while St/X was opened, I got a abort: The process cannot access the file because it is being used by another process message. After I have exited the St/X the update when smoothly:

PS C:\prg_sdk\stx_dev\stx-jv\build\stx\libbasic> hg up -r c40c9ef127f2
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

Maybe there could be a connection with the locked files and the message? Could it be that St/X does not correctly close handles after commits?

[Patrik Svestka]

What is the difference between linux and windows version? Why this error does not propagate on linux?