We dont support serialization of asynch. i/o agains the same fileobject. :-D Fileobject have 4 members used for this lock:
ULONG Waiters; ULONG Busy; PVOID LastLock; KEVENT Lock;
afaics, its basically a mutex but its reimplemented as a "file object lock" to support alertable waits and customized rundown.
I remeber seeing some of these members incorrectly used in Cc for some bizzare synch. but it might be removed now...
G.
Ge van Geldorp wrote:
I'm working on bug 713 (http://www.reactos.com/bugzilla/show_bug.cgi?id=713 for the click-happy). What I have found is this:
- Telnet opens a socket
- Sending and receiving are handled by different threads, let's call them S
and R
- Thread R starts a recv() operation, which is translated to an ioctl on the
socket
- No data is available, so thread R blocks, waiting for FileObject->Event
- I type something, which is handled by thread S. Thread S starts a send()
operation.
- Again translated to an ioctl on the socket. Since this is the same socket
as used by S, the FileObject will be the same
- The send can complete immediately, IoCompleteRequest is called which sets
the FileObject->Event.
- Thread R is unblocked, the event it was waiting for was set by thread S.
However, the irp of thread R was never completed. The recv() call returns with bogus info.
- Thread R starts another recv(). When some data arrives from the server,
two irps are waiting for it. This eventually leads to the crash.
The fundamental problem seems to be multiple overlapping I/O operations which all use FileObject->Event to signal their completion. I have no idea how to fix that...
Gé van Geldorp.
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev