[ros-dev] I/O subsystem question

Gunnar Dalsnes hardon at online.no
Mon Sep 12 13:16:06 CEST 2005


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 at reactos.com
> http://reactos.com:8080/mailman/listinfo/ros-dev
> 
> 
> 


More information about the Ros-dev mailing list