Re: Windows timeout during ORB shutdown

--=-F9BgC7Co4+BKAuzTQiG+
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2026-01-26 at 21:48 +0000, Thomas Ives via omniORB-list wrote:


> I have managed to reproduce the issue by modifying echo/eg1.cc
> example.=C2=A0=20
> =C2=A0=C2=A0This test reliably reproduces the issue for me (whereas for m=
y
> Tango=20
> test I will occasionally not see the problem).=C2=A0 I have attached the=
=20
> modified eg1.cc program and a log of the output it produces
> (eg1.out).=C2=A0=20
> =C2=A0=C2=A0As far as I can tell, the assertion failure is due to a bug i=
n
> omniORB and not the program.

Thank you for spending the time to investigate that and provide a
simple reproducer.

> omniORB is assuming that waiting for scanGranularity seconds is
> enough time for all the dedicated threads to finish, however, on
> Windows each of those threads can wait for up to scanGranularity
> seconds itself, so if you have many threads the main thread times out
> waiting.

Yes, that is indeed what is happening. It is a race condition between
the timeout of the thread trying to stop everything and the threads
that are blocked waiting for incoming calls. The mistake is to use the
same scanGranularity value for both.

> =C2=A0> As you say, Windows makes life much harder than Linux (and Unix
> platforms) because shutting down a socket does not wake up threads
> waiting on it, hence all the issues with timeouts.
>=20
> I have done some digging into the winsock2 documentation and it
> appears that we can wake up the selecting thread using Win32's
> QueueUserAPC function.=C2=A0 The winsock2 documentation for select[1] say=
s
> the following in a note towards the end of the remarks:

That is interesting, but I think it is too fragile to use here.=C2=A0In you=
r
test, all the connection worker threads are blocked in select, but in
general there is no way to know if the worker threads are in select at
the time, or whether they are busy doing some other work that might be
damaged by the asynchronous call. As you say in your code comment,
there are also situations in which there are multiple threads handling
a single connection, which would make it much more complex.

I think a much safer fix is simply to make sure that the shutdown
timeout is longer than the scanGranularity, to give all the threads
time to stop if they are idle. Obviously that does not make it
completely impossible for the situation to occur, but I think it will
always work in practice.

Real servers, as opposed to test code, are not expected to rapidly
start and stop repeatedly, so I don't think the additional significant
complexity to make it faster would be a good idea.

I'm going to commit the attached small change. I suggest that for your
test code you set scanGranularity to 1. That will mean it takes a
second to stop, which is still quite long, but faster than the default
5 seconds.

Thanks,

Duncan.

--=20
Duncan Grisby <[email protected]>

--=-F9BgC7Co4+BKAuzTQiG+
Content-Disposition: attachment; filename="shutdown_timeout.patch"
Content-Type: text/x-patch; name="shutdown_timeout.patch"; charset="UTF-8"
Content-Transfer-Encoding: base64

SW5kZXg6IG9tbmlPUkIvc3JjL2xpYi9vbW5pT1JCL29yYmNvcmUvZ2lvcFNlcnZlci5jYwo9PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09Ci0tLSBvbW5pT1JCL3NyYy9saWIvb21uaU9SQi9vcmJjb3JlL2dpb3BTZXJ2ZXIuY2Mg
ICAgICAgKHJldmlzaW9uIDY4MDkpCisrKyBvbW5pT1JCL3NyYy9saWIvb21uaU9SQi9vcmJjb3Jl
L2dpb3BTZXJ2ZXIuY2MgICAgICAgKHdvcmtpbmcgY29weSkKQEAgLTQ4OCw3ICs0ODgsNyBAQAoK
ICAgdW5zaWduZWQgbG9uZyB0aW1lb3V0OwogICBpZiAob3JiUGFyYW1ldGVyczo6c2NhbkdyYW51
bGFyaXR5KQotICAgIHRpbWVvdXQgPSBvcmJQYXJhbWV0ZXJzOjpzY2FuR3JhbnVsYXJpdHk7Cisg
ICAgdGltZW91dCA9IG9yYlBhcmFtZXRlcnM6OnNjYW5HcmFudWxhcml0eSAqIDI7CiAgIGVsc2UK
ICAgICB0aW1lb3V0ID0gNTsKCg==


--=-F9BgC7Co4+BKAuzTQiG+
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
omniORB-list mailing list
[email protected]
https://www.omniorb-support.com/mailman/listinfo/omniorb-list

--=-F9BgC7Co4+BKAuzTQiG+--