Overlapped IO was Re: [Mono-list] threads and Async Socket methods

[P Oscar Boykin]

--5oH/S/bF6lOfqCQb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Sorry for replying to myself, but I thought some other people might
benefit from seeing a few references.

It seems what I am interested in is the following question:

Does Mono support overlapped IO on the asynchronous socket calls.
Winsock does support this.  It seems the .Net framework is supposed to
support this.  When I put a server under heavily load, this fails on
mono 0.31 on debian unstable.

Any Mono guru's out there care to comment on Overlapped IO on Sockets in
mono?

I have found some background links discussing various issues with
overlapped IO and unix:

Wine has had to deal with this:
http://www.winehq.org/hypermail/wine-devel/2001/11/0020.html
http://www.kerneltraffic.org/wine/wn20020726_130.html#3

Here is a discussion about IO models in winsock programming which sings
the praises of overlapped IO:
http://tangentsoft.net/wskfaq/articles/io-strategies.html

I am having a hard time writing a test case only using sockets which can
expose (what a believe to be) the bug.  In my code, I have ~50 sockets
which are created with a lot of data being copied between the sockets.
At that point, I start to see sockets which just stop working.  For
instance, BeginSend methods stop calling the callback function, and the
socket basically gets stuck (some internal deadlock maybe?)

I looked at the code for the System.Net.Sockets.Socket class.  It seems
to implement the BeginSend and BeginReceive methods just using a Worker
without any attempt at any kind of thread safety (which I can imagine
would cause problems if you call interleaved BeginSend and BeginRead).

Best,
Oscar

On Tue, Apr 27, 2004 at 05:33:04PM -0700, P Oscar Boykin wrote:
> Hello All,
>=20
> I have some code that does asynchronous Socket.BeginSend and
> Socket.BeginReceive calls.
>=20
> My question is the following:
>=20
> 1) The documentation (in monodoc) says that no instance members of
> Socket are guaranteed to be thread safe.
>=20
> 2) Given the above, is it safe to have a BeginSend call active while a
> BeginReceive call is also active?  Given that the "under the hood" it
> appears that these methods are implemented with threads.
>=20
> So, to make it clear, if I have code like:
>=20
> --------------
> BeginSend()
> BeginReceive()
>=20
> [ other stuff here ]
>=20
> EndReceive()
> EndSend()
> -------------
>=20
> is this safe?  To me, it would seem like it would not be safe if none of
> the members are guaranteed to be thread safe, but on the other hand, I
> have a C# networking book that has examples such as this.
>=20
> The reason I ask is that I have some code that (on mono 0.31) appears
> that *SOMETIMES* the BeginSend never calls the callback function to
> indicate that it finished (and the other side never gets the data).
> This is happening while a BeginReceive() is active.
>=20
> When I see bugs that happen only sometimes, it usually makes me worry
> about thread safety.  It would be nice if the Begin* methods were
> designed such that there could be more than one of them active at a time
> (particularly, it would be nice to have a send going on while a receive
> was also active).
>=20
> Am I expecting too much here?
>=20
> Thanks,
> Oscar
> --=20
> boykin@pobox.com    http://pobox.com/~boykin    jabber: johnynek@jabber.o=
rg
> fingerprint=3DD250 4AD9 4544 B7D2 A17C  911D D608 D387 6718 D75F
> Hague Convention is Bad News: http://www.gnu.org/philosophy/hague.html



--=20
boykin@pobox.com    http://pobox.com/~boykin    jabber: johnynek@jabber.org
fingerprint=3DD250 4AD9 4544 B7D2 A17C  911D D608 D387 6718 D75F
Read about net freedom: http://www.politechbot.com/

--5oH/S/bF6lOfqCQb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAkB7m1gjTh2cY118RAkp6AJ9206JKjyEt86Hr+wLK7/n6wAizVQCfYZ1m
rlkC00b3hULMFtCu6LOI4YE=
=9oS2
-----END PGP SIGNATURE-----

--5oH/S/bF6lOfqCQb--