Discussions

The C# equivalent is pretty close, making both arguments for/against (at least for this specific example) a little off the base.

IEnumberable<MyType> bfs(MyType e)
{
   List<MyType> q = new ArrayList();
   e.Mark();
   yield return e;
   while (q.Count > 0)
   {
      object u = q[0];
      q.RemoveAt(0);
      foreach (MyType v in u.EdgeIterator())
      {
         if (!v.Marked)
         {
            v.Mark();
            yield return v;
            q.Add(v);
         }
      }
   }
}

foreach(MyType v in bfs(e))
{
   Console.WriteLine(v);
}

Note: This was typed free form and may contain numerous errors, but it should illustrate the point.

Which is worse:

1)  Ability to crash a browser (in pre-beta form) and *maybe* run code via the bug found in less than 15 minutes.

2) Ability to "root" a Mac system (in production form) in 30 minutes.

http://www.zdnet.com.au/news/security/soa/Mac_OS_X_hacked_in_less_than_30_minutes/0,2000061744,39241748,00.htm

Note that I'm only semi-serious.

PaoloM wrote:

Fair enough

In 2011 Unix won't exist anymore, so....

Yeah, right.  And regardless, there'll still be a lot of POSIX code out there, and not being able to run that code on Windows would be a bad thing.

PaoloM wrote:

wkempf wrote: 1) This is just SFU bundled instead of being seperate tool.

Yes.

wkempf wrote: 2) This means the demise of SFU except on this specific Windows version, which is a bad, BAD thing.  MS, rethink this.

Wowowow... where did you get this? SFU is already bundled in 2003R2, that didn't kill the standalone version, right?

It was reported some time ago and even discussed on here.  Granted all of the facts are not "out there", but I've seen little information to contradict this.

http://channel9.msdn.com/ShowPost.aspx?PostID=108647

1) This is just SFU bundled instead of being seperate tool.

2) This means the demise of SFU except on this specific Windows version, which is a bad, BAD thing.  MS, rethink this.

3) There are X servers available for SFU, so yes, it's any application written to be portable, where portable means meant to run on numerous POSIX compliant systems.  There may need to be some code tweaks, but this is true when porting to any of the currently available POSIX systems.

Oh, and if IE included a d/l manager (even a very simple one), this wouldn't be an issue.  So only two d/ls occur at once, if I try to d/l a third it won't "timeout" on me, it will just go into the manager as a pending d/l until one of the others finishes.  Although it would be nice in todays large pipe environments to d/l more at once, for bandwidth leaching reasons the RFC makes some sense, but it's poor UI to let the user timeout and have to go back and find the link again.

Maurits wrote:

Does this stop you from browsing the site further if you are downloading two files from the site?

On the other hand you could download as many files as you wanted if they were all on different sites.

No, it won't limit the browsing, because that doesn't use persistent connections.  I think, any way.  But with out reading the entire spec, I don't see how a download would be considered a persistent connection either.  Longer lived, sure, but still not persistent.

BTW, what's the registry hack to change the number?

The most common reasons for multithreading don't have to do with performance (responsiveness, which is different, is the number one reason, and simplifying code algorithms is another, though this requires work since synchronization concerns can actually make the code more complex).

Other's mention blocking I/O as a reason to use more threads.  The reasoning here is, generally, responsiveness (and code simplification) not performance.  To illustrate, many network applications will allocate one thread per connection.  This makes for a relatively responsive application and is certainly one of the easiest ways to code this scenario.  However, it doesn't scale well.  Such applications that need to scale would instead use async I/O and a thread pool with a distinct number of threads (with the algorithm you mention being a fair, though not perfect, algorithm to follow).  Remember, every thread allocated must be managed by the scheduler, and the more threads there are the more work must be done.  Also, synchronization requirements become a bottle neck with more threads, because there's more contention on shared resources.

Remember, however, that algorithms like the one given are just rules of thumb.  It doesn't take into consideration several factors that will effect the outcome:

1) Thread scheduling, which is platform specific and usually intentionally under specified.

2) Multi-tasking.  Most platforms, and all that support threading that I'm aware of, are multi-tasking systems.  In addition to your program there will be N other programs running each with their own set of threads, and all of them will be taking time on the CPUs as the scheduler sees fit.

3) Specific algorithms.  If most of the program will be I/O bound but there's a set of tasks that are CPU bound placing the CPU bound tasks in seperate threads can often increase the actual performance, not just the responsiveness, of the application, up to a point (which is dependent on the scheduler and the total number of threads in all processes, and so isn't precisely in your control).

ScanIAm wrote:

I think it would be a good idea.  Apple's hardware is usually high quality...higher than your average 3rd world sweatshop built hardware, and the products 'work together' very well.  They still have a good selling point and from a consistency standpoint, running windows would force the 'black turtleneck' crowd to STFU.

Undoubtedly there's a segment that would purchase these, for the reasons you give.  But that segment isn't large enough to support Apple.  Entry level users are going to opt for a Dell, or similar, for the price point and support.  Hardcore users would opt for building their own or going with various lesser known systems, usually choosing AMD processors, in order to get the best price/performance ratio.  These two segments make up the majority of computer buyers.  This leaves only a very small segment left that fit your description.

Apple currently survives in this area because they have total lock in (and yet many of the OSS crowd loves Apple and hates MS because MS tries to lock you in, go figure).  After the move to x86, Apple is already going to have a difficult time keeping this lock in.  Remove the OS from the equation and replace it with Windows, and they won't have any chance of retaining the lock in.  At that point, their only consumers will be the complete die hards and a few yuppies.  Everyone else, including a large part of their current consumer base, will just be laughing at the concept of buying the overpriced Apple.  In order to survive, they'd have to cut prices, at which point they become just another Dell/HP.

http://www.pcmag.com/article2/0,1895,1925239,00.asp

Yeah, Apple could switch to Windows and compete/survive solely on it's "high end x86 PC" line.  Not.