Re: [PATCH 1/4] server: Move completion from async object to async queue.
"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes:
Real Name: Erich Hoover
Description: It seems that the completion information should be associated with the async queue, rather than the async object, since the completion information for a file handle can be updated after an async IO has been queued. So, the attached patch moves the completion information from the async object into the async queue so that we can properly handle associating a completion with a file descriptor after an async IO is queued (part 2).
Does it even need to be stored in the queue then? Why not retrieve it from the fd when needed? -- Alexandre Julliard julliard(a)winehq.org
On Fri, Jun 1, 2012 at 8:57 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes:
Real Name: Erich Hoover
Description: It seems that the completion information should be associated with the async queue, rather than the async object, since the completion information for a file handle can be updated after an async IO has been queued. So, the attached patch moves the completion information from the async object into the async queue so that we can properly handle associating a completion with a file descriptor after an async IO is queued (part 2).
Does it even need to be stored in the queue then? Why not retrieve it from the fd when needed?
Sorry I didn't reply to this sooner, I've been at a wedding at just got back to the land of the Internet. I believe that it really does need to be stored in the queue, otherwise in the case that the async operation has not completed when the file descriptor is closed then the cancel completion will not be able to propagate. Erich
"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes:
Sorry I didn't reply to this sooner, I've been at a wedding at just got back to the land of the Internet. I believe that it really does need to be stored in the queue, otherwise in the case that the async operation has not completed when the file descriptor is closed then the cancel completion will not be able to propagate.
I don't think that you can have an async queue that outlives its file descriptor. -- Alexandre Julliard julliard(a)winehq.org
On Mon, Jun 4, 2012 at 2:53 AM, Alexandre Julliard <julliard(a)winehq.org> wrote:
... I don't think that you can have an async queue that outlives its file descriptor.
Well, maybe I screwed something up - but when I tried to access the descriptor like that it caused segfaults in some of the tests. What I found was that neither create_async_queue or create_async increment the refcount on the file descriptor, but create_async does increment the refcount on the async queue so that the async queue will live throughout the life of the async. So, what appeared to happen is this: 1) A file descriptor is created. 2) An async operation is queued on the file descriptor. 3) The file descriptor is closed (queuing the async to wake up and contact user space). 4) The file descriptor is destroyed because its refcount reaches zero. 5) The async operation returns from user space with completion information for the operation. 6) Accessing the completion from the no-longer existing file descriptor causes a crash. I tried having the async and/or the async queue increment the refcount for the file descriptor, but that caused a host of other problems (mainly file descriptors never closing). So, I'm pretty sure that the completion information needs to be held separately in the async queue - but I can go back and double check that this is the case if you'd like. Erich Hoover ehoover(a)mines.edu
"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes:
Well, maybe I screwed something up - but when I tried to access the descriptor like that it caused segfaults in some of the tests. What I found was that neither create_async_queue or create_async increment the refcount on the file descriptor, but create_async does increment the refcount on the async queue so that the async queue will live throughout the life of the async. So, what appeared to happen is this: 1) A file descriptor is created. 2) An async operation is queued on the file descriptor. 3) The file descriptor is closed (queuing the async to wake up and contact user space). 4) The file descriptor is destroyed because its refcount reaches zero. 5) The async operation returns from user space with completion information for the operation. 6) Accessing the completion from the no-longer existing file descriptor causes a crash.
I tried having the async and/or the async queue increment the refcount for the file descriptor, but that caused a host of other problems (mainly file descriptors never closing). So, I'm pretty sure that the completion information needs to be held separately in the async queue - but I can go back and double check that this is the case if you'd like.
It may have to be moved to the queue upon shutdown when the file descriptor is released, but I don't see any reason to maintain two copies of the same information. -- Alexandre Julliard julliard(a)winehq.org
participants (2)
-
Alexandre Julliard -
Erich E. Hoover