WSAEWOULDBLOCK?

It seems that WSAEWOULDBLOCK is handled properly during socket
reads/writes, but not for socket connects?

Specifically,

restartableError: code
 "Test if this is a process block or restartable error."
^#('EWOULDBLOCK' 'EAGAIN' 'EINTR' 'EALREADY' 'ENODATA'
'ERROR_UNEXP_NET_ERROR' 'ERROR_TOO_MANY_POSTS') includes: (self
errorSymbolFor: code)

which is then used in,

privateReadInto: buffer startingAt: index for: count

and

privateWriteFrom: buffer startingAt: index for: count

to retry when it happens. Is there a reason why it's not handled in

connectTo: aSocketAddress timeout: ms
 [self primConnectTo: aSocketAddress]
        on: self errorReporter operationStartedSignal, "EINPROGRESS"
                self errorReporter notReadySignal "EALREADY"
        do: [:ex | self handleAsyncConnect: ex timeout: ms]

I am considering changing this to,

connectTo: aSocketAddress timeout: ms
 [self primConnectTo: aSocketAddress]
        on: self errorReporter operationStartedSignal, "EINPROGRESS"
                self errorReporter notReadySignal, "EALREADY"
                self errorReporter needRetrySignal "EWOULDBLOCK"
        do: [:ex | self handleAsyncConnect: ex timeout: ms]

Thoughts? If this seems unreasonable, what is the proper way to handle
these on connection?

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

Quoting http://msdn2.microsoft.com/en-us/library/ms740668.aspx,

WSAEWOULDBLOCK
10035

Resource temporarily unavailable.

This error is returned from operations on nonblocking sockets that
cannot be completed immediately, for example recv when no data is queued
to be read from the socket. It is a nonfatal error, and the operation
should be retried later. It is normal for WSAEWOULDBLOCK to be reported
as the result from calling connect on a nonblocking SOCK_STREAM socket,
since some time must elapse for the connection to be established.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

No takers?

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

Seems reasonable enough to me, but I don't really know enough about the area. Created AR 53509.

At 05:59 PM 12/7/2007, Boris Popov wrote:

Quoting http://msdn2.microsoft.com/en-us/library/ms740668.aspx,

WSAEWOULDBLOCK
10035

Resource temporarily unavailable.

This error is returned from operations on nonblocking sockets that
cannot be completed immediately, for example recv when no data is queued
to be read from the socket. It is a nonfatal error, and the operation
should be retried later. It is normal for WSAEWOULDBLOCK to be reported
as the result from calling connect on a nonblocking SOCK_STREAM socket,
since some time must elapse for the connection to be established.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Boris Popov [[hidden email]]
> Sent: Friday, December 07, 2007 2:57 PM
> To: [hidden email]
> Subject: WSAEWOULDBLOCK?
>
> It seems that WSAEWOULDBLOCK is handled properly during socket
> reads/writes, but not for socket connects?
>
> Specifically,
>
> restartableError: code
>  "Test if this is a process block or restartable error."
> ^#('EWOULDBLOCK' 'EAGAIN' 'EINTR' 'EALREADY' 'ENODATA'
> 'ERROR_UNEXP_NET_ERROR' 'ERROR_TOO_MANY_POSTS') includes: (self
> errorSymbolFor: code)
>
> which is then used in,
>
> privateReadInto: buffer startingAt: index for: count
>
> and
>
> privateWriteFrom: buffer startingAt: index for: count
>
> to retry when it happens. Is there a reason why it's not handled in
>
> connectTo: aSocketAddress timeout: ms
>  [self primConnectTo: aSocketAddress]
>       on:     self errorReporter operationStartedSignal, "EINPROGRESS"
>                self errorReporter notReadySignal "EALREADY"
>       do: [:ex | self handleAsyncConnect: ex timeout: ms]
>
> I am considering changing this to,
>
> connectTo: aSocketAddress timeout: ms
>  [self primConnectTo: aSocketAddress]
>       on:     self errorReporter operationStartedSignal, "EINPROGRESS"
>                self errorReporter notReadySignal, "EALREADY"
>                self errorReporter needRetrySignal "EWOULDBLOCK"
>       do: [:ex | self handleAsyncConnect: ex timeout: ms]
>
> Thoughts? If this seems unreasonable, what is the proper way to handle
> these on connection?
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.

Pete Hatch writes:

WSAEWOULDBLOCK is mapped in the Windows VM to EWOULDBLOCK.  This error is mapped to the #notReadySignal.  E.g.:

         OSErrorHolder errorSignals at: 'EWOULDBLOCK'

evaluates to

         OSErrorHolder notReadySignal


At 05:59 PM 12/7/2007, Boris Popov wrote:

Quoting http://msdn2.microsoft.com/en-us/library/ms740668.aspx,

WSAEWOULDBLOCK
10035

Resource temporarily unavailable.

This error is returned from operations on nonblocking sockets that
cannot be completed immediately, for example recv when no data is queued
to be read from the socket. It is a nonfatal error, and the operation
should be retried later. It is normal for WSAEWOULDBLOCK to be reported
as the result from calling connect on a nonblocking SOCK_STREAM socket,
since some time must elapse for the connection to be established.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Boris Popov [[hidden email]]
> Sent: Friday, December 07, 2007 2:57 PM
> To: [hidden email]
> Subject: WSAEWOULDBLOCK?
>
> It seems that WSAEWOULDBLOCK is handled properly during socket
> reads/writes, but not for socket connects?
>
> Specifically,
>
> restartableError: code
>  "Test if this is a process block or restartable error."
> ^#('EWOULDBLOCK' 'EAGAIN' 'EINTR' 'EALREADY' 'ENODATA'
> 'ERROR_UNEXP_NET_ERROR' 'ERROR_TOO_MANY_POSTS') includes: (self
> errorSymbolFor: code)
>
> which is then used in,
>
> privateReadInto: buffer startingAt: index for: count
>
> and
>
> privateWriteFrom: buffer startingAt: index for: count
>
> to retry when it happens. Is there a reason why it's not handled in
>
> connectTo: aSocketAddress timeout: ms
>  [self primConnectTo: aSocketAddress]
>       on:     self errorReporter operationStartedSignal, "EINPROGRESS"
>                self errorReporter notReadySignal "EALREADY"
>       do: [:ex | self handleAsyncConnect: ex timeout: ms]
>
> I am considering changing this to,
>
> connectTo: aSocketAddress timeout: ms
>  [self primConnectTo: aSocketAddress]
>       on:     self errorReporter operationStartedSignal, "EINPROGRESS"
>                self errorReporter notReadySignal, "EALREADY"
>                self errorReporter needRetrySignal "EWOULDBLOCK"
>       do: [:ex | self handleAsyncConnect: ex timeout: ms]
>
> Thoughts? If this seems unreasonable, what is the proper way to handle
> these on connection?
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.

Alan,

 

Humm… Shouldn’t I have seen an attempt at #handleAsyncConnect:timeout: somewhere in the exception stack if the handler was invoked?

 

[… IPs are replaced with XXXX …]

 

==2007/12/10==14:28:02==BEGIN RUNTIME DIAGNOSTIC DUMP

Note: this file stored in VisualWorks #source (UTF-8) encoding

 

Cause of Dump: WSAEWOULDBLOCK

Image Identification: 'An anonymous image'

Smalltalk Version: 'VisualWorks®, 7.5 of April 16, 2007'

Object Memory versionId: #[62 41 62 96 75 0 0 0 62 41 62 96]

Class creating this dump: RuntimeImageDumper

------------------------------------------------------------

Active Process

Context Stack:

[1]        SocketAccessor class(OSErrorHolder class)>>reportOn:

[2]        SocketAccessor(OSErrorHolder)>>reportError

[3]        SocketAccessor>>primConnectTo:

[4]        optimized [] in SocketAccessor>>connectTo:timeout:

[5]        BlockClosure>>on:do:

[6]        SocketAccessor>>connectTo:timeout:

[7]        SocketAccessor>>connectTo:

[8]        optimized [] in SocketAccessor class>>newTCPclientToHost:port:

[9]        BlockClosure>>ifCurtailed:

[10]       SocketAccessor class>>newTCPclientToHost:port:

[11]       VisualWave.IPClient>>establishSocket

[12]       VisualWave.IPClient>>connect

 

 

Unhandled Exception:

            class: OsNeedRetryError

            creator: OSErrorHolder notReadySignal

            errorString: WSAEWOULDBLOCK

            parameter: an active SocketAccessor

 

 

Initial Context Stack Arguments:

[1] SocketAccessor class(OSErrorHolder class)>>reportOn:

            Receiver: (id=13486) SocketAccessor

            Arg1: (id=1916) an active SocketAccessor

[2] SocketAccessor(OSErrorHolder)>>reportError

            Receiver: (id=1916) an active SocketAccessor

[3] SocketAccessor>>primConnectTo:

            Receiver: (id=1916) an active SocketAccessor

            Arg1: (id=12041) IPSocketAddress(port#8321 at:XXXX)

[5] BlockClosure>>on:do:

            Receiver: (id=5782) BlockClosure [] in SocketAccessor>>connectTo:timeout:

            Arg1: (id=15907) ExceptionSet (OSErrorHolder notReadySignal OSErrorHolder operationStartedSignal)

            Arg2: (id=9648) BlockClosure [] in SocketAccessor>>connectTo:timeout:

[6] SocketAccessor>>connectTo:timeout:

            Receiver: (id=1916) an active SocketAccessor

            Arg1: (id=12041) IPSocketAddress(port#8321 at:XXXX)

            Arg2: (id=75000) 75000

[7] SocketAccessor>>connectTo:

            Receiver: (id=1916) an active SocketAccessor

            Arg1: (id=12041) IPSocketAddress(port#8321 at:XXXX)

[9] BlockClosure>>ifCurtailed:

            Receiver: (id=3389) BlockClosure [] in SocketAccessor class>>newTCPclientToHost:port:

            Arg1: (id=13514) BlockClosure [] in SocketAccessor class>>newTCPclientToHost:port:

[10] SocketAccessor class>>newTCPclientToHost:port:

            Receiver: (id=13486) SocketAccessor

            Arg1: (id=7255) 'XXXX'

            Arg2: (id=8321) 8321

[11] VisualWave.IPClient>>establishSocket

            Receiver: (id=996) a VisualWave.IPClient

[12] VisualWave.IPClient>>connect

            Receiver: (id=996) a VisualWave.IPClient

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

---

From: Alan Knight [mailto:[hidden email]]
Sent: Tuesday, December 11, 2007 5:14 PM
To: Boris Popov; [hidden email]
Subject: Re: WSAEWOULDBLOCK?

 

Pete Hatch writes:

WSAEWOULDBLOCK is mapped in the Windows VM to EWOULDBLOCK.  This error is mapped to the #notReadySignal.  E.g.:

         OSErrorHolder errorSignals at: 'EWOULDBLOCK'

evaluates to

         OSErrorHolder notReadySignal


At 05:59 PM 12/7/2007, Boris Popov wrote:

Quoting http://msdn2.microsoft.com/en-us/library/ms740668.aspx,

WSAEWOULDBLOCK
10035

Resource temporarily unavailable.

This error is returned from operations on nonblocking sockets that
cannot be completed immediately, for example recv when no data is queued
to be read from the socket. It is a nonfatal error, and the operation
should be retried later. It is normal for WSAEWOULDBLOCK to be reported
as the result from calling connect on a nonblocking SOCK_STREAM socket,
since some time must elapse for the connection to be established.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Boris Popov [[hidden email]]
> Sent: Friday, December 07, 2007 2:57 PM
> To: [hidden email]
> Subject: WSAEWOULDBLOCK?
>
> It seems that WSAEWOULDBLOCK is handled properly during socket
> reads/writes, but not for socket connects?
>
> Specifically,
>
> restartableError: code
>  "Test if this is a process block or restartable error."
> ^#('EWOULDBLOCK' 'EAGAIN' 'EINTR' 'EALREADY' 'ENODATA'
> 'ERROR_UNEXP_NET_ERROR' 'ERROR_TOO_MANY_POSTS') includes: (self
> errorSymbolFor: code)
>
> which is then used in,
>
> privateReadInto: buffer startingAt: index for: count
>
> and
>
> privateWriteFrom: buffer startingAt: index for: count
>
> to retry when it happens. Is there a reason why it's not handled in
>
> connectTo: aSocketAddress timeout: ms
>  [self primConnectTo: aSocketAddress]
>       on:     self errorReporter operationStartedSignal, "EINPROGRESS"
>                self errorReporter notReadySignal "EALREADY"
>       do: [:ex | self handleAsyncConnect: ex timeout: ms]
>
> I am considering changing this to,
>
> connectTo: aSocketAddress timeout: ms
>  [self primConnectTo: aSocketAddress]
>       on:     self errorReporter operationStartedSignal, "EINPROGRESS"
>                self errorReporter notReadySignal, "EALREADY"
>                self errorReporter needRetrySignal "EWOULDBLOCK"
>       do: [:ex | self handleAsyncConnect: ex timeout: ms]
>
> Thoughts? If this seems unreasonable, what is the proper way to handle
> these on connection?
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.

--

Alan Knight [|], Cincom Smalltalk Development

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

Alan,

Here's an attempt at a workspace to, hopefully, shed some light at the
issue that I am seeing which may enable someone to point me in the right
direction as far as proper handling is concerned.

The principle is simple, create a server and try to create 100 sockets
to it a few times. We'll do one run (A) without any error handling and
one run (B) with a handler for OSErrorHolder notReadySignal. We'll do
both with varying timeouts hoping that longer timeouts will mean fewer
failures in the first run and fewer retries in the second run. The
results so far seem to hint that default handler isn't doing what I
think it should be doing, in other words I would have expected not to
have to handle #notReadySignal myself, especially with longer timeouts,

resetting timeout to 1 second

A: running without explicit handler
attempt # 1 managed to create 68 sockets

B: running with explicit retry handler
attempt # 1 managed to create 100 sockets; had to retry 0 times
attempt # 2 managed to create 100 sockets; had to retry 1 times
attempt # 3 managed to create 100 sockets; had to retry 1 times
attempt # 4 managed to create 100 sockets; had to retry 1 times
attempt # 5 managed to create 100 sockets; had to retry 1 times

resetting timeout to 5 second

A: running without explicit handler
attempt # 1 managed to create 30 sockets

B: running with explicit retry handler
attempt # 1 managed to create 100 sockets; had to retry 0 times
attempt # 2 managed to create 100 sockets; had to retry 1 times
attempt # 3 managed to create 100 sockets; had to retry 1 times
attempt # 4 managed to create 100 sockets; had to retry 1 times
attempt # 5 managed to create 100 sockets; had to retry 1 times

resetting timeout to 10 second

A: running without explicit handler
attempt # 1 managed to create 68 sockets

B: running with explicit retry handler
attempt # 1 managed to create 100 sockets; had to retry 0 times
attempt # 2 managed to create 100 sockets; had to retry 1 times
attempt # 3 managed to create 100 sockets; had to retry 1 times
attempt # 4 managed to create 100 sockets; had to retry 0 times
attempt # 5 managed to create 100 sockets; had to retry 0 times

Is this of any help to you?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Alan Knight [mailto:[hidden email]]
> Sent: Tuesday, December 11, 2007 5:14 PM
> To: Boris Popov; [hidden email]
> Subject: Re: WSAEWOULDBLOCK?
>
> Pete Hatch writes:
>
> WSAEWOULDBLOCK is mapped in the Windows VM to EWOULDBLOCK.  This error
is is
> queued
> to be read from the socket. It is a nonfatal error, and the
> operation
> should be retried later. It is normal for WSAEWOULDBLOCK to be
> reported
> as the result from calling connect on a nonblocking SOCK_STREAM
> socket,
> since some time must elapse for the connection to be
established. please to that
> is
> > private and confidential. If you have received it in error,
please

By the way, case A doesn't always fail on the first attempt, just want
to make sure that doesn't raise any unneeded red flags,

A: running without explicit handler
attempt # 1 managed to create 100 sockets
attempt # 2 managed to create 100 sockets
attempt # 3 managed to create 100 sockets
attempt # 4 managed to create 100 sockets
attempt # 5 managed to create 30 sockets

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
right
> direction as far as proper handling is concerned.
>
> The principle is simple, create a server and try to create 100 sockets
to
> it a few times. We'll do one run (A) without any error handling and
one
> run (B) with a handler for OSErrorHolder notReadySignal. We'll do both
> with varying timeouts hoping that longer timeouts will mean fewer
failures
> in the first run and fewer retries in the second run. The results so
far
> seem to hint that default handler isn't doing what I think it should
be error that
> > cannot be completed immediately, for example recv when no data
is
> > queued
> > to be read from the socket. It is a nonfatal error, and the
> > operation
> > should be retried later. It is normal for WSAEWOULDBLOCK to be
> > reported
> > as the result from calling connect on a nonblocking SOCK_STREAM
> > socket,
> > since some time must elapse for the connection to be
established. is
> > private and confidential. If you have received it in error,
please (self handled "EWOULDBLOCK"
> > >       do: [:ex | self handleAsyncConnect: ex timeout: ms]
> > >
> > > Thoughts? If this seems unreasonable, what is the proper way
to message
> > > header. Unless otherwise indicated, it contains information
that
> > is
> > > private and confidential. If you have received it in error,
please

Last bit for today is a log of 2 more runs, with 30 second timeout and
75 second one (which is a default as far as 7.5 is concerned),

resetting timeout to 30 second

A: running without explicit handler
attempt # 1 managed to create 100 sockets
attempt # 2 managed to create 68 sockets

B: running with explicit retry handler
attempt # 1 managed to create 100 sockets; had to retry 0 times
attempt # 2 managed to create 100 sockets; had to retry 1 times
attempt # 3 managed to create 100 sockets; had to retry 1 times
attempt # 4 managed to create 100 sockets; had to retry 0 times
attempt # 5 managed to create 100 sockets; had to retry 0 times

resetting timeout to 75 second

A: running without explicit handler
attempt # 1 managed to create 30 sockets

B: running with explicit retry handler
attempt # 1 managed to create 100 sockets; had to retry 0 times
attempt # 2 managed to create 100 sockets; had to retry 1 times
attempt # 3 managed to create 100 sockets; had to retry 1 times
attempt # 4 managed to create 100 sockets; had to retry 0 times
attempt # 5 managed to create 100 sockets; had to retry 0 times

It seems that timeout really doesn't affect the outcome at all; I still
need to handle the exception myself and retry it to connect
successfully.

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Boris Popov
> Sent: Tuesday, December 11, 2007 7:24 PM
> To: 'Alan Knight'; '[hidden email]'; 'Peter Hatch'
> Subject: RE: WSAEWOULDBLOCK?
>
> By the way, case A doesn't always fail on the first attempt, just want
to the
> > issue that I am seeing which may enable someone to point me in the
right
> > direction as far as proper handling is concerned.
> >
> > The principle is simple, create a server and try to create 100
sockets
> to
> > it a few times. We'll do one run (A) without any error handling and
one
> > run (B) with a handler for OSErrorHolder notReadySignal. We'll do
both
> > with varying timeouts hoping that longer timeouts will mean fewer
> failures
> > in the first run and fewer retries in the second run. The results so
far
> > seem to hint that default handler isn't doing what I think it should
be error that
> > > cannot be completed immediately, for example recv when no data
is
> > > queued
> > > to be read from the socket. It is a nonfatal error, and the
> > > operation
> > > should be retried later. It is normal for WSAEWOULDBLOCK to be
> > > reported
> > > as the result from calling connect on a nonblocking SOCK_STREAM
> > > socket,
> > > since some time must elapse for the connection to be
established. is
> > > private and confidential. If you have received it in error,
please (self handled "EWOULDBLOCK"
> > > >       do: [:ex | self handleAsyncConnect: ex timeout: ms]
> > > >
> > > > Thoughts? If this seems unreasonable, what is the proper way
to message
> > > > header. Unless otherwise indicated, it contains information
that
> > > is
> > > > private and confidential. If you have received it in error,
please

So, I believe what's going on is that we do handle the exception and attempt to do the retry. If it succeeds after that, we're fine. But if, after the timeout, it still hasn't connected, then we pass the exception up to the application, which has to decide what to do.

It seems like we get occurences where waiting doesn't help, but trying again does. So I think the appropriate thing is precisely that your application should catch the notReadySignal, meaning that it couldn't become ready within the timeout interval, and try again to set it up.

At 10:35 PM 12/11/2007, Boris Popov wrote:

Last bit for today is a log of 2 more runs, with 30 second timeout and
75 second one (which is a default as far as 7.5 is concerned),

resetting timeout to 30 second

A: running without explicit handler
attempt # 1 managed to create 100 sockets
attempt # 2 managed to create 68 sockets

B: running with explicit retry handler
attempt # 1 managed to create 100 sockets; had to retry 0 times
attempt # 2 managed to create 100 sockets; had to retry 1 times
attempt # 3 managed to create 100 sockets; had to retry 1 times
attempt # 4 managed to create 100 sockets; had to retry 0 times
attempt # 5 managed to create 100 sockets; had to retry 0 times

resetting timeout to 75 second

A: running without explicit handler
attempt # 1 managed to create 30 sockets

B: running with explicit retry handler
attempt # 1 managed to create 100 sockets; had to retry 0 times
attempt # 2 managed to create 100 sockets; had to retry 1 times
attempt # 3 managed to create 100 sockets; had to retry 1 times
attempt # 4 managed to create 100 sockets; had to retry 0 times
attempt # 5 managed to create 100 sockets; had to retry 0 times

It seems that timeout really doesn't affect the outcome at all; I still
need to handle the exception myself and retry it to connect
successfully.

Thanks!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Boris Popov
> Sent: Tuesday, December 11, 2007 7:24 PM
> To: 'Alan Knight'; '[hidden email]'; 'Peter Hatch'
> Subject: RE: WSAEWOULDBLOCK?
>
> By the way, case A doesn't always fail on the first attempt, just want
to
> make sure that doesn't raise any unneeded red flags,
>
> A: running without explicit handler
> attempt # 1 managed to create 100 sockets
> attempt # 2 managed to create 100 sockets
> attempt # 3 managed to create 100 sockets
> attempt # 4 managed to create 100 sockets
> attempt # 5 managed to create 30 sockets
>
> Thanks!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.
>
> > -----Original Message-----
> > From: Boris Popov
> > Sent: Tuesday, December 11, 2007 7:12 PM
> > To: 'Alan Knight'; [hidden email]; 'Peter Hatch'
> > Subject: RE: WSAEWOULDBLOCK?
> >
> > Alan,
> >
> > Here's an attempt at a workspace to, hopefully, shed some light at
the
> > issue that I am seeing which may enable someone to point me in the
right
> > direction as far as proper handling is concerned.
> >
> > The principle is simple, create a server and try to create 100
sockets
> to
> > it a few times. We'll do one run (A) without any error handling and
one
> > run (B) with a handler for OSErrorHolder notReadySignal. We'll do
both
> > with varying timeouts hoping that longer timeouts will mean fewer
> failures
> > in the first run and fewer retries in the second run. The results so
far
> > seem to hint that default handler isn't doing what I think it should
be
> > doing, in other words I would have expected not to have to handle
> > #notReadySignal myself, especially with longer timeouts,
> >
> > resetting timeout to 1 second
> >
> > A: running without explicit handler
> > attempt # 1 managed to create 68 sockets
> >
> > B: running with explicit retry handler
> > attempt # 1 managed to create 100 sockets; had to retry 0 times
> > attempt # 2 managed to create 100 sockets; had to retry 1 times
> > attempt # 3 managed to create 100 sockets; had to retry 1 times
> > attempt # 4 managed to create 100 sockets; had to retry 1 times
> > attempt # 5 managed to create 100 sockets; had to retry 1 times
> >
> > resetting timeout to 5 second
> >
> > A: running without explicit handler
> > attempt # 1 managed to create 30 sockets
> >
> > B: running with explicit retry handler
> > attempt # 1 managed to create 100 sockets; had to retry 0 times
> > attempt # 2 managed to create 100 sockets; had to retry 1 times
> > attempt # 3 managed to create 100 sockets; had to retry 1 times
> > attempt # 4 managed to create 100 sockets; had to retry 1 times
> > attempt # 5 managed to create 100 sockets; had to retry 1 times
> >
> > resetting timeout to 10 second
> >
> > A: running without explicit handler
> > attempt # 1 managed to create 68 sockets
> >
> > B: running with explicit retry handler
> > attempt # 1 managed to create 100 sockets; had to retry 0 times
> > attempt # 2 managed to create 100 sockets; had to retry 1 times
> > attempt # 3 managed to create 100 sockets; had to retry 1 times
> > attempt # 4 managed to create 100 sockets; had to retry 0 times
> > attempt # 5 managed to create 100 sockets; had to retry 0 times
> >
> > Is this of any help to you?
> >
> > -Boris
> >
> > --
> > +1.604.689.0322
> > DeepCove Labs Ltd.
> > 4th floor 595 Howe Street
> > Vancouver, Canada V6C 2T5
> > http://tinyurl.com/r7uw4
> >
> > [hidden email]
> >
> > CONFIDENTIALITY NOTICE
> >
> > This email is intended only for the persons named in the message
> > header. Unless otherwise indicated, it contains information that is
> > private and confidential. If you have received it in error, please
> > notify the sender and delete the entire message including any
> > attachments.
> >
> > Thank you.
> >
> > > -----Original Message-----
> > > From: Alan Knight [[hidden email]]
> > > Sent: Tuesday, December 11, 2007 5:14 PM
> > > To: Boris Popov; [hidden email]
> > > Subject: Re: WSAEWOULDBLOCK?
> > >
> > > Pete Hatch writes:
> > >
> > > WSAEWOULDBLOCK is mapped in the Windows VM to EWOULDBLOCK.  This
error
> > is
> > > mapped to the #notReadySignal.  E.g.:
> > >
> > >          OSErrorHolder errorSignals at: 'EWOULDBLOCK'
> > >
> > > evaluates to
> > >
> > >          OSErrorHolder notReadySignal
> > >
> > >
> > > At 05:59 PM 12/7/2007, Boris Popov wrote:
> > >
> > >
> > >   Quoting http://msdn2.microsoft.com/en-us/library/ms740668.aspx
> > > < http://msdn2.microsoft.com/en-us/library/ms740668.aspx> ,
> > >
> > >   WSAEWOULDBLOCK
> > >   10035
> > >
> > >   Resource temporarily unavailable.
> > >
> > >   This error is returned from operations on nonblocking sockets
that
> > >   cannot be completed immediately, for example recv when no data
is
> > > queued
> > >   to be read from the socket. It is a nonfatal error, and the
> > > operation
> > >   should be retried later. It is normal for WSAEWOULDBLOCK to be
> > > reported
> > >   as the result from calling connect on a nonblocking SOCK_STREAM
> > > socket,
> > >   since some time must elapse for the connection to be
established.
> > >
> > >   -Boris
> > >
> > >   --
> > >   +1.604.689.0322
> > >   DeepCove Labs Ltd.
> > >   4th floor 595 Howe Street
> > >   Vancouver, Canada V6C 2T5
> > >    http://tinyurl.com/r7uw4 < http://tinyurl.com/r7uw4>
> > >
> > >   [hidden email]
> > >
> > >   CONFIDENTIALITY NOTICE
> > >
> > >   This email is intended only for the persons named in the message
> > >   header. Unless otherwise indicated, it contains information that
is
> > >   private and confidential. If you have received it in error,
please
> > >   notify the sender and delete the entire message including any
> > >   attachments.
> > >
> > >   Thank you.
> > >
> > >   > -----Original Message-----
> > >   > From: Boris Popov [ [hidden email]
> > > <[hidden email]> ]
> > >   > Sent: Friday, December 07, 2007 2:57 PM
> > >   > To: [hidden email]
> > >   > Subject: WSAEWOULDBLOCK?
> > >   >
> > >   > It seems that WSAEWOULDBLOCK is handled properly during socket
> > >   > reads/writes, but not for socket connects?
> > >   >
> > >   > Specifically,
> > >   >
> > >   > restartableError: code
> > >   >  "Test if this is a process block or restartable error."
> > >   > ^#('EWOULDBLOCK' 'EAGAIN' 'EINTR' 'EALREADY' 'ENODATA'
> > >   > 'ERROR_UNEXP_NET_ERROR' 'ERROR_TOO_MANY_POSTS') includes:
(self
> > >   > errorSymbolFor: code)
> > >   >
> > >   > which is then used in,
> > >   >
> > >   > privateReadInto: buffer startingAt: index for: count
> > >   >
> > >   > and
> > >   >
> > >   > privateWriteFrom: buffer startingAt: index for: count
> > >   >
> > >   > to retry when it happens. Is there a reason why it's not
handled
> > > in
> > >   >
> > >   > connectTo: aSocketAddress timeout: ms
> > >   >  [self primConnectTo: aSocketAddress]
> > >   >       on:     self errorReporter operationStartedSignal,
> > > "EINPROGRESS"
> > >    >                self errorReporter notReadySignal "EALREADY"
> > >   >       do: [:ex | self handleAsyncConnect: ex timeout: ms]
> > >   >
> > >   > I am considering changing this to,
> > >   >
> > >   > connectTo: aSocketAddress timeout: ms
> > >   >  [self primConnectTo: aSocketAddress]
> > >   >       on:     self errorReporter operationStartedSignal,
> > > "EINPROGRESS"
> > >    >                self errorReporter notReadySignal, "EALREADY"
> > >    >                self errorReporter needRetrySignal
"EWOULDBLOCK"
> > >   >       do: [:ex | self handleAsyncConnect: ex timeout: ms]
> > >   >
> > >   > Thoughts? If this seems unreasonable, what is the proper way
to
> > > handle
> > >   > these on connection?
> > >   >
> > >   > Cheers!
> > >   >
> > >   > -Boris
> > >   >
> > >   > --
> > >   > +1.604.689.0322
> > >   > DeepCove Labs Ltd.
> > >   > 4th floor 595 Howe Street
> > >   > Vancouver, Canada V6C 2T5
> > >   > http://tinyurl.com/r7uw4 < http://tinyurl.com/r7uw4>
> > >   >
> > >   > [hidden email]
> > >   >
> > >   > CONFIDENTIALITY NOTICE
> > >   >
> > >   > This email is intended only for the persons named in the
message
> > >   > header. Unless otherwise indicated, it contains information
that
> > > is
> > >   > private and confidential. If you have received it in error,
please
> > >   > notify the sender and delete the entire message including any
> > >   > attachments.
> > >   >
> > >   > Thank you.
> > >
> > >
> > > --
> > > Alan Knight [|], Cincom Smalltalk Development
> > > [hidden email]
> > > [hidden email]
> > > http://www.cincom.com/smalltalk < http://www.cincom.com/smalltalk>