> 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/>
-------------------------------------------------------------------------------
--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe: email tcl...@aj... with the
word UNSUBSCRIBE as the subject.
|
