Re: struct async-private - now tested and cleaned up

[Alexandre Julliard]

Martin Wilck  writes:
> It is a polished resubmit of my former posting, without the GetOverlappedResult() stuff
> which will follow in a separate patch. It is against clean CVS 2002-01-15.
>
> I would be really grateful if this patch was applied, because it is a prerequisite for me to
> get going with Winsock2 overlapped IO.

The comm.c part doesn't apply, are you sure this is against a clean
CVS?  You should probably consider using cvs diff, it helps making
sure you do the diff against the right file.

Also note that because of dll separation you cannot use functions like
register_async() from winsock. If absolutely necessary they could be
exported, but I think it would be much better to use straight server
calls (and in theory these functions shouldn't be used from comm.c
either).

struct async-private - now tested and cleaned up

On 16 Jan 2002, Alexandre Julliard wrote:
> The comm.c part doesn't apply, are you sure this is against a clean
> CVS?  You should probably consider using cvs diff, it helps making
> sure you do the diff against the right file.

I admit I had to use -l on it to get it to apply, but I didn't think
anything of that at the time.

Lawson

struct async-private - now tested and cleaned up

[Martin Wilck]

On 16 Jan 2002, Alexandre Julliard wrote:
> Also note that because of dll separation you cannot use functions like
> register_async() from winsock. If absolutely necessary they could be
> exported, but I think it would be much better to use straight server
> calls (and in theory these functions shouldn't be used from comm.c
> either).

Hmm. I guess I don't fully understand dll separation. Are you telling me
that the scheduling mechanism for async requests shouls be implemented
separately in each DLL? If so, I could have spared my efforts to build
a "generic" interface to async requests. I'd just mention that
this would be error-prone, because different parts of wine with
equivalent functionality would need to be maintained. Note
that an app is allowed to mix ReadFile() and WSARecv() calls
for a socket (however braindead that would be). I'd assume that
in Windows there must be a hidden layer for asynchronous requests
somewhere, too, or do you think their respective code is completely
separate?

What would be the "clean" way in theory?

Martin