Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004466OCamlOCaml windowspublic2007-12-12 07:532015-12-09 15:47
Assigned To 
PlatformOSOS Version
Product Version3.10.0 
Target Version4.03.0+dev / +beta1Fixed in Version4.03.0+dev / +beta1 
Summary0004466: on Windows not handling reads and writes to same socket
DescriptionI am making a program which constantly listens on a socket for incoming data, in order to check for timeouts, but seems to act strange on Windows. It will not register a socket available for reading if it was written to after it started listening. Since that sentence doesn't make sense, here's a layout:

1. One thread runs " [socket] [] [] timeout"
2. Another thread writes out to the socket
3. Data is received from a remote program

In this case, the "select" function should return as soon as 3. occurs. In Linux and OSX, this is exactly what happens. However it always times out in Windows.
Additional InformationThe attached files demonstrate the problem. The receiver simply responds to all incoming data. The sender sends three "packets":
The first packet is sent before the select occurs
The second and third packets are sent right after a select is started up
Compile the files separately. I used
ocamlopt -o send3-timeout -thread unix.cmxa threads.cmxa
ocamlopt -o recv3-timeout -thread unix.cmxa threads.cmxa

Then run the receiver in one window:
recv3-timeout 45678
And the sender in another:

Under Linux, the sender returns with the following:
Selected after 0.000013 seconds
Selected after 0.052056 seconds
Selected after 0.052001 seconds

However, in Windows it returns the following:
Selected after 0.016000 seconds
TIMEOUT after 10.000000 seconds
Selected after 0.000000 seconds

Under Windows, the second select fails, but the second response is picked up immediately by the third select.
TagsNo tags attached.
Attached Fileszip file icon [^] (1,670 bytes) 2007-12-12 07:53

- Relationships
related to 0005325resolved Blocked Unix.recv in one thread blocks Unix.send in another thread under Windows 
related to 0005578closed Windows: Exception raised when reading from a socket 
related to 0006771resolvedxleroy Thread lock up 

-  Notes
omion (reporter)
2007-12-12 07:54

And... I just realized I selected "Caml-light" for the submission. This actually occurs in OCaml 3.10.0 for Windows.
omion (reporter)
2008-01-09 21:32

In the meantime, I made a nasty hack that can get around this issue. I made a socketpair called (fake_in, fake_out) (not easy in Windows since the Unix.socketpair is not supported) which I use to "reset" the select.

Whenever I write something to the real socket, I write to fake_in as well. Then I use the following for the select statement:
select [fake_out;real_sock] [] [] timeout

This will return fake_out whenever something was written to the real socket, so I can re-run the select statement and not have the problem.

However, right around the time I added this statement in the program, it started crashing (it comes up with the Windows "do you want to debug?" dialog). I have no idea if it is related, but it looks fishy.
Christoph Bauer (reporter)
2009-08-14 12:06
edited on: 2009-08-14 15:42

seems to be solved with ocaml >= 3.11.0.

Selected after 0.000000 seconds
Selected after 0.063000 seconds
Selected after 0.047000 seconds

Tested with the patch from 0004844.

Updated: On the other hand in a more complex program I see also
such a strange behaviour. I do something like
select [sock] [] [sock] 1.0
No timeout
select [] [sock] [sock] 1.0
No timeout
select [sock] [] [sock] 1.0
select [sock] [] [sock] 1.0
No timeout (exactly 0.0s)

Update II:
The problem indeed seems to be, that sock is used twice in my select calls.
There is a difference if the third list is empty.

omion (reporter)
2013-12-22 07:21

I'm making another program which would run into this bug, but it looks like it's fixed if the new[*] select function (from revision 10467, I think) is used.

For the line in
match [sock] [] [] timeout with

I added Unix.stdin:
match [sock] [] [Unix.stdin] timeout with

This forces the new function, returning good values:
Selected after 0.000000 seconds
Selected after 0.062000 seconds
Selected after 0.062000 seconds

It's still a bit hackish, since I have no idea if/when Unix.stdin would actually be selected with an exception, but it seems to work...

[*] Well... "new" in relation to this bug report. I guess that function's 3 years old already.
xleroy (administrator)
2015-11-28 12:19

Any update on this problem report for the most recent OCaml release (4.02.3) or even the development version? In the absence of additional information, I move to close it.
omion (reporter)
2015-11-28 21:33
edited on: 2015-11-29 20:19

I just did a 64-bit MSVC compile of commit e22eabe (4.03.0+dev11-2015-10-19), and the issue is still there.

It looks like bypassing the "classic" select function (as win32unix/select.c calls it) fixes the problem. However, I wouldn't be able to say if this is a safe change - most of that file is way above my head.

My fix in the past was to create an alternative to the [edit: I mean Unix.socket] function which does not set SO_SYNCHRONOUS_NONALERT. That solution works fine for how I use sockets, but has problems with some functions (see the attempted fix for 0005325 and the resulting issues in 0005578).

xleroy (administrator)
2015-11-29 14:56

Thank you for the quick retest, and for identifying SO_SYNCHRONOUS_NONALERT as the likely culprit. It's time for us to do something about that.
xleroy (administrator)
2015-12-04 15:00

See proposed fix in [^]
xleroy (administrator)
2015-12-09 15:47

Fix committed to trunk, will be in 4.03

- Issue History
Date Modified Username Field Change
2007-12-12 07:53 omion New Issue
2007-12-12 07:53 omion File Added:
2007-12-12 07:54 omion Note Added: 0004386
2008-01-09 21:32 omion Note Added: 0004407
2008-01-10 11:23 doligez Status new => acknowledged
2008-01-10 11:23 doligez Category Caml-light => OCaml general
2009-08-14 12:06 Christoph Bauer Note Added: 0005045
2009-08-14 12:49 Christoph Bauer Note Edited: 0005045
2009-08-14 15:38 Christoph Bauer Note Edited: 0005045
2009-08-14 15:42 Christoph Bauer Note Edited: 0005045
2010-04-18 20:35 xleroy Status acknowledged => assigned
2010-04-18 20:35 xleroy Assigned To => gildor
2012-07-11 16:01 doligez Target Version => 4.01.0+dev
2012-07-31 13:37 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-15 11:34 doligez Target Version 4.00.1+dev => 4.00.2+dev
2012-09-15 11:35 doligez Assigned To gildor =>
2012-09-15 11:35 doligez Status assigned => acknowledged
2013-07-09 14:06 doligez Category OCaml general => OCaml windows
2013-07-09 14:06 doligez Target Version 4.00.2+dev => 4.01.0+dev
2013-07-24 22:28 doligez Target Version 4.01.0+dev => 4.01.1+dev
2013-12-22 07:21 omion Note Added: 0010760
2014-05-25 20:20 doligez Target Version 4.01.1+dev => 4.02.0+dev
2014-07-31 17:30 doligez Target Version 4.02.0+dev => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-26 16:50 doligez Target Version undecided => 4.02.2+dev / +rc1
2015-01-16 21:05 doligez Target Version 4.02.2+dev / +rc1 => 4.02.3+dev
2015-07-15 16:21 doligez Target Version 4.02.3+dev => 4.03.0+dev / +beta1
2015-11-28 12:19 xleroy Note Added: 0014884
2015-11-28 12:19 xleroy Status acknowledged => feedback
2015-11-28 21:33 omion Note Added: 0014891
2015-11-28 21:33 omion Status feedback => new
2015-11-28 21:34 omion Note Edited: 0014891 View Revisions
2015-11-28 21:34 omion Note Edited: 0014891 View Revisions
2015-11-29 14:56 xleroy Note Added: 0014892
2015-11-29 14:56 xleroy Status new => confirmed
2015-11-29 14:56 xleroy Relationship added related to 0005325
2015-11-29 14:57 xleroy Relationship added related to 0005578
2015-11-29 15:05 xleroy Relationship added related to 0006671
2015-11-29 15:05 xleroy Relationship deleted related to 0006671
2015-11-29 15:05 xleroy Relationship added related to 0006771
2015-11-29 20:19 omion Note Edited: 0014891 View Revisions
2015-12-04 15:00 xleroy Note Added: 0015032
2015-12-09 15:47 xleroy Note Added: 0015082
2015-12-09 15:47 xleroy Status confirmed => resolved
2015-12-09 15:47 xleroy Resolution open => fixed
2015-12-09 15:47 xleroy Fixed in Version => 4.03.0+dev / +beta1

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker