[Mono-bugs] [Bug 67355][Wis] Changed - [PPC] XSP has a jit bug which causes failures
bugzilla-daemon@bugzilla.ximian.com
bugzilla-daemon@bugzilla.ximian.com
Thu, 14 Oct 2004 00:28:13 -0400 (EDT)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by grompf@sublimeintervention.com.
http://bugzilla.ximian.com/show_bug.cgi?id=67355
--- shadow/67355 2004-10-01 13:17:09.000000000 -0400
+++ shadow/67355.tmp.18816 2004-10-14 00:28:13.000000000 -0400
@@ -1,14 +1,14 @@
Bug#: 67355
Product: Mono: Runtime
Version: unspecified
-OS:
+OS: unknown
OS Details: osx 10.3.5
Status: NEW
Resolution:
-Severity:
+Severity: Unknown
Priority: Wishlist
Component: misc
AssignedTo: mono-bugs@ximian.com
ReportedBy: grompf@sublimeintervention.com
QAContact: mono-bugs@ximian.com
TargetMilestone: ---
@@ -41,6 +41,32 @@
session1.aspx test. Submit the callback a few times and you will get an exception.
I'm going to work more on atomicizing a cross-appdomain call that can replicate the same
behaviour but have been unsuccesful so far..
-kangaroo
+
+------- Additional Comments From grompf@sublimeintervention.com 2004-10-14 00:28 -------
+I dug more into this bug today; and with further looking it appears this might not be a JIT
+bug. It appears to be a socket blocking bug. I'm not sure why my other patch masks this
+behaviour; but when setting the client socket to Blocking; XSP starts behaving as it should
+again. Perhaps its a jit speed difference to x86 why this hasn't been noticed there?
+
+-kangaroo
+
+Index: ApplicationServer.cs
+=======================================================
+============
+RCS file: /cvs/public/xsp/server/ApplicationServer.cs,v
+retrieving revision 1.11
+diff -u -r1.11 ApplicationServer.cs
+--- ApplicationServer.cs 3 Oct 2004 22:02:40 -0000 1.11
++++ ApplicationServer.cs 14 Oct 2004 02:39:59 -0000
+@@ -307,6 +307,7 @@
+
+ allSockets.Remove (s);
+ timeouts.Remove (s);
++ s.Blocking = true;
+ IWorker worker = webSource.CreateWorker (s, this);
+ ThreadPool.QueueUserWorkItem (new WaitCallback
+(worker.Run));
+ }