Re: [ros-dev] I/O subsystem question

[Gunnar Dalsnes]

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