Newbie switching from TCL

[Jeffrey Hobbs]

Paul Duffin wrote:
> 
> Alex Martelli wrote:
> >
> > "Robin Becker" <robin at jessikat.fsnet.co.uk> wrote in message
> > news:WMCNkKAOfDp5EwGf at jessikat.fsnet.co.uk...
> > > I use select only because it's in python for sockets. In win32 Tcl
> > > I used the event model which relied on threading to do the notification.
> > > I regard that as rather strange especially since as you so helpfully
> > > point out there are dozens of ways to do it.
> >
> > Tcl's architects may have chosen that architecture for portability
> > reasons.  There may be a few ways to do general eventing on
> > System V, a couple more to do it on BSD, a few more to do it
> > in VMS, yet others for Win32, MacOS, BeOS, etc, etc -- but if
> > you want to use a single architecture and do a decent job of
> > covering them all, you're probably left with auxiliary thread[s]
> > as maybe the only choice that stands a chance.
> >
> 
> I think the reason why Tcl's architects chose that approach was that they
> simply do not know all of the Windows specific ways of doing things. They
> are also UNIX people at heart so "select/poll" *IS* the only way to do
> event driven I/O.
> 
> They started off with the mapping from select to WaitForMultipleObjects
> and tried to make everything fit into that. By the sounds of it there
> may be better ways to do this.
> 
> BTW. Does overlapping I/O work with sockets ?

To set the record straight, the guys that did the initial Windows port
were Windows-savvy (if still likely with a Unix bent).  However, the
real PITA that they have to deal with is support for Windows 3.1 and
16 bit programs (shudder).  That's been totally ripped out since the
last few versions, but 5 years ago that was important to some.  Although
it has been ripped out, we haven't had the opportunity to rearchitect
the Windows I/O from the ground up.   And yes, we have looked at
(are looking at) overlapped I/O.

At the time, the way it was implemented in Tcl was about the most
efficient working cross-platform way to do things.  Even now it isn't
a bad way, just a stylistic choice.  Life would be much easier if one
could ignore the entire Win9* line as well, because remember that it
isn't just about choosing the best "documented" API, you have to choose
one that works, and MS is notoriously bad for good-looking APIs that
all need work-arounds.

-- 
   Jeffrey Hobbs                     The Tcl Guy
   hobbs at ajubasolutions.com       Ajuba Solutions (née Scriptics)