Debug and Fix `shutdown`

[Yaxuan-w]

Previously, when testing newest fdtable interface with Lind general test suite, the shutdown test failed, and error seems related to close. Open an issue to track the progress of debug and fixes.

[Yaxuan-w]

After perfroming close() on one process, read() syscall in another syscall should return immediately because of socket has already been closed. However, we found rust libc will never return. My analysis is that after porting new fdtables, code logic of inner close should also be changed. Further analysis and fixes plan is needed. This bug should be able to deal issues of shutdown etc syscall as well. So I comment here.

[Yaxuan-w]

There’s an occasional bug in the shutdown.c test but other tests related to shutdown works well (shutdown_fork.c and simple programs I wrote). The cause is that during close_syscall, an exit_syscall is also triggered as part of the handling process. Sometimes, exit_syscall removes the fdtable first, while close_syscall runs slower. As a result, close_syscall might attempt to close a file descriptor that has already been removed by exit_syscall.

To address the modifications in fdtable, I propose adding locks. Given the high frequency of read and write operations on the fdtable interface, I recommend using Arc for efficient synchronization. However, I'd like to open this up for discussion before proceeding with the fix. That would be really helpful if @JustinCappos @rennergade @yzhang71 have any suggestions / comments on this issue.

[JustinCappos]

I don't think this needs to directly go into fdtables. The issue here isn't locking, as I understand it, but it's what happens when a thread is aborted.

The big question from yesterday is what happens when an shutdown occurs. What happens if you pthread kill a Rust thread? Should we be doing this? What happens? Is this ever likely to be safe? We need to understand these things first.

[rennergade]

I thought about this a bit last night and it should be simple enough to safely exit threads within trusted code (RawPOSIX) by adding an exit flag and checking it (a bit more complicated when in blocking kernel calls but we can implement the same thing we did in RustPOSIX with timeouts).

There are less options for exiting while stuck in untrusted code (ie userspace loops etc). I wonder if we can harness this to handle them: bytecodealliance/wasmtime#1490