A Quantum Immortal

Last night I discovered this piece of code (simplified version):

private void Foo()
{
  bool b = false;
  new Thread((ThreadStart)delegate { b = true;}).Start();
  WaitForBool(b);
}

private void WaitForBool(bool b)
{
  while (!b)
  {
     Thread.Sleep(1000);
  }
}

I was immediately filled with disgust. How could someone write such a function (WaitForBool), which is one big bug? Of course the waiting will never be over, because bool is a value type, and no external influence can modify its value.

Later, I realized the fool is me.

I ran into this code a while back, and it did have a “ref” bool, which means it can be modified by the external thread. Resharper helpfully displayed a tip “this parameter can be declared as a value” , which I took without thinking too much about the consequences (I trust Resharper too much sometimes, it appears). So I deleted the “ref” with Resharper’s help and created the bug myself without noticing.

(As a side note, of course this method of waiting for a bool should never be used – use ManualResetEvent instead).

Update
Fixed in the next Resharper build (Resharper 4.0.1, build 913), within a few hours of reporting it. Cool.

I’m a square myself.

Still alpha, but starting today we are open for business – try it out yourself at www.delver.com.

I won’t write about the user experience much because I want you to try for yourselves, and because many others have done so already.

Gmail recently added a nice feature: Down the page (near the space usage stats) there is the text “Last account activity”. If you click on details, you get the recent gmail sessions you’ve had, and can even disconnect them. Useful for checking that nobody’s using your credentials from anywhere…

Embedding the above image link doesn’t work, and I have no idea why 🙁
Here is a link to the image.

P.S.
Thanks to Eran for the tip.

Update – it seems the pesky problem we were having for HTTP/1.1 is actually still relevant to us. The problem is we cannot force .NET framework to properly close a response stream within the HttpWebResponse – the thread just waits forever. Sucks, but it appears we have to use HTTP/1.0 for the time being, at least until we manage to hack it someway (understand how the class works internally and hack it away).

Working for the Diggers team in a search engine, a large chunk of our tasks is writing sophisticated web crawlers.

We were using HTTP/1.0 because we didn’t need any features in 1.0, and to circumvent a problem we thought we had with 1.1. On such a crawl mission, I discovered today that MSN’s site does not support HTTP/1.0.

After another check we found that the above problem does not affect us, because it is only relevant the Microsoft Compact Framework. But it’s still a rather shock to find a large site (even though it’s Microsoft) that utterly does not support HTTP/1.0.

Try it yourself – go to about:config in Firefox and set network.http.version to 1.0, and then surf to MSN. You’ll get a blank page. What actually happens is MSN assumes you’re using HTTP/1.1, and sends you a chunked response. Your web browser will not parse a chunked response, and rightly so.

(Needless to say that HTTP is supposed to be backward compatible).