From: Andreas K. <a.k...@we...> - 2000-07-27 19:28:01
|
--------; charset=us-ascii > FYI, > 8.3.2 has some more testing to be done, and then some backporting of > items that went into the main branch (8.4). It should be out by > mid-August. > In working with 8.3.2, we realized that there will be a need for and > 8.3.3 to work on limitations inherent in the Windows OS and how we > manage sockets with Tcl. Currently we can only service 64 > simultaneous socket requests because that's what the Windows select > can manage per thread. What an OS :(. Now there was that slip of paper ... Ah, here. ~~~~~~~~~~~~~~~~~~ Windows 95: n. 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. ~~~~~~~~~~~~~~~~~~ > The solution will be to spin a thread per socket instead (as > lightweight as possible). Questions coming to my mind: Would it be much more complex to spin new threads only as the limit on the previous ones is reached, i.e. only every 64 sockets ? Or would that complexity outweigh the benefits we can get from having less threads around ? I'm worried that we will run into some limit on the number of threads supported by Win* instead. > At the same time we have to solve the problem with the memory leak > in using Windows threads when the C runtime is accessed (leading to > things like the 4K mem leak per exec call on Windows). > We already have some thoughts, but it will take some time to get the > solution right. We want to get the 8.3.2 changes out because it > will be important for everybody to have a real distributed version > of Tcl with the corrected stacked channel code, among other changes > that will be in 8.3.2. No release date for 8.3.3 at this time. -- So long, Andreas Kupries <a.k...@we...> <http://www.purl.org/NET/akupries/> ------------------------------------------------------------------------------- |