Re: struct async_private needs generalization for Winsock

[Mike McCormack]

Hi Martin,

That's pretty quick and thorough work!
> I try to summarize the differences between the two request types

here:
> - Winsock async requests have a WSAOVERLAPPED struct rather than
>
> OVERLAPPED. Unlike File I/O, the routines complete if any
>   positive number of bytes is read (there's no such thing as
>   BytesToRead).

That case is similar to serial I/O when timeouts are
(interval=-1,const=0,total=0), isn't it? The file I/O code doesn't
really handle it properly yet either, as it just falls into a busy
loop in the original ReadFile... hmmm.
> - Unlike File I/O, The WSAOVERLAPPED struct is *not* accessed in any

Looks like you sorted this out in the other thread. i'd suggest you
use the WSAOVERLAPPED fields in the same way as OVERLAPPED where ever
possible, or not use them at all. i think you need the completion
status in the Internal member... HasOverlappedCompleted is a macro
that checks there.
> [These are the differences I've come across so far, there may be

more.]

The way i've done the serial overlapped code so far is to implement
what i *think* should be done, then wait for people to complain about
their programs not working. You won't have to wait too long...
> I'd therefore recommend the following, similar to the treatment of
> "struct object" and derived types in the server code:
>
> struct async_private;
> typedef void (*async_handler)(struct async_private *ovp);

..

That looks OK to me. i'm not going to complain about it too much if
i'm not doing the work to implement it ;-)

Mike

------------------------------------------
mailto:[e-mail]
ph [phone]

__________________________________________________________________
Get your free Australian email account at http://www.Looksmart.com.au

struct async_private needs generalization for Winsock

[Martin Wilck]

Hi Mike,
> That case is similar to serial I/O when timeouts are
> (interval=-1,const=0,total=0), isn't it? The file I/O code doesn't
> really handle it properly yet either, as it just falls into a busy
> loop in the original ReadFile... hmmm.

I believe it's simpler for sockets because I'll use separate async handler
routines which simply behave differently. I am not sure if it'll be
possible to mimic the Windows behaviour *exactly* ... I guess there'll
always be some sort of randomness involved in how many bytes are received
in a single recv(). I worry about the MSG_PARTIAL flag, which doesn't
seem to have a one-to-one Unix equivalent.
> That looks OK to me. i'm not going to complain about it too much if
> i'm not doing the work to implement it ;-)

Don't worry. I'm already working on it.
I assume you have (a) test program(s) for the serial code - I would
be grateful if you could run that against my patch (coming soon).

Btw I'd like to hear your optinion on the discussion between Alexandre and
myself in this thread.

Cheers, Martin