Re: RESEND: Handle shortened *optval arg. in WS_setsockopt / WS_SO_RCVTIMEO

[Rein Klazes]

On Tue, 24 Sep 2002 16:10:43 -0500, you wrote:
> +	    if (level == SOL_SOCKET && optname == SO_RCVTIMEO && optlen < sizeof(struct timeval)) {
> +	        if (optlen == sizeof(time_t)) {
> +	            /* Apparently WinSock will accept a shortened struct timeval.

In Unix the arg optval points to a struct timeval, in windows to a
(32bit) int, no mystery here. The latter is the timeout in
milliseconds. Further a non-zero timeout less then 500 (msec) is taken
as 500 msec.
> +		       FIXME: should we do the same for SO_SNDTIMEO? */

Of course, its the same issue.
> +	            WARN("Short struct timeval in SO_RCVTIMEO: assuming time_t\n");
> +		    tval.tv_sec = *(time_t*)optval;
> +		    tval.tv_usec = 0;

You will need to convert from milliseconds here.


Unfortunately this does not work (a recv timing out). The socket in
wine is non-blocking internally, any blocking will be done in the
function do_block() using a select(). SO_RCVTMO has no effect there.

Rein.
-- 
Rein Klazes
rklazes(a)xs4all.nl

RESEND: Handle shortened *optval arg. in WS_setsockopt / WS_SO_RCVTIMEO

[Greg Turner]

awesome, thanks for your input Rein!  I am no unix sockets guru (nor, 
obviously, am I a winsock guru ;) so this is really helpful, I'll try 
and submit a revision to my revision (which is apparently already in 
wine).  That explains the time value out I was seeing of 10,000!  3 
hours sounded like an awfully long time to me so I probably should have 
guessed those were mili's :).

Basically, from your advice, I see two options.  One, the obvious one, 
which I'll implement for now, is to convert miliseconds-> 
<seconds,miliseconds> and be done with it.  The other would be a 
"correct" solution that actually works -- judging by your post, just 
converting the arguments won't, and I'll need to learn a little bit more 
about wine-winsock to make it do the right thing.  I'll do the easy 
thing, post it to patches, then look into do_block and get back to the 
list if I find that this is all beyond my abilities (a quite probable 
scenario ;)

Thanks again for the hand-holding, keep it coming, please, as I may be 
somewhat "out of my league" here, and I don't want to screw up wine out 
of ignorance.

-- 
Greg Turner <gmturner007(a)ameritech.net>

"Waiting periods are only a step. Registration is only a step.
The prohibition of private firearms is the goal."
  -U.S. Attorney General Janet Reno, December 1993


Rein Klazes wrote:
> On Tue, 24 Sep 2002 16:10:43 -0500, you wrote:
> > +	    if (level == SOL_SOCKET && optname == SO_RCVTIMEO && optlen < sizeof(struct timeval)) {
> > +	        if (optlen == sizeof(time_t)) {
> > +	            /* Apparently WinSock will accept a shortened struct timeval.
>
> In Unix the arg optval points to a struct timeval, in windows to a
> (32bit) int, no mystery here. The latter is the timeout in
> milliseconds. Further a non-zero timeout less then 500 (msec) is taken
> as 500 msec.
> > +		       FIXME: should we do the same for SO_SNDTIMEO? */
>
> Of course, its the same issue.
> > +	            WARN("Short struct timeval in SO_RCVTIMEO: assuming time_t\n");
> > +		    tval.tv_sec = *(time_t*)optval;
> > +		    tval.tv_usec = 0;
>
> You will need to convert from milliseconds here.
>
> Unfortunately this does not work (a recv timing out). The socket in
> wine is non-blocking internally, any blocking will be done in the
> function do_block() using a select(). SO_RCVTMO has no effect there.
>
> Rein.