If not, what would be the easiest and/or best way to add this support ?
I see three possibilities:
- somehow make the open command accept a pipe name as argument. Since
CreateFile accepts this, perhaps open can be made to do so as well?
This would give us at least client side named pipe support.
- Add a hook for CreateNamedPipe and then call Tcl_MakeFileChannel on
the returned handle. I don't know how well this would work given the
differing semantics of pipes and files
- write a full fledged channel driver ? This would probably be the most
flexible but sounds like a lot of work. What would be a good starting
point to do this? The Tcl core's TCP/IP code or the iocp extension or
something else?
I'm thinking about adding this to TWAPI and was wondering where to
start. If someone has already done this, that would be even better!
/Ashok
Personally, If I had to start this, I'd start with a full-fledged
channel driver in an extension as it would give me the freedom to
discover the sweet spot with special option flags for the accessor
command and custom fconfigures if only for the "academic" approach.
I'd also go with overlapped-I/O with event notification. That's the
most portable and should work on ME as well as XP and the like.
Iocpsock uses overlapped-I/O, but NT-only CompletionPort notification.
I also suggest that for selfish reasons because I need a job scheduler
myself for the next step with IOCPSOCK to work with WSAEventSelect :)
The issue with waitable handles (sockets or namedpipes) is the 64 handle
limit per WaitFor* call. Or think of it as one job scheduler thread can
only listen to a max of 64 handles (really 63 cause we'll need one as a
shutdown event). Thus you'd need a pool of threads that can grow and
shrink along with the management of those threads.
A ways back I started looking at RegisterWaitForSingleObject which does
about half the work, but never got much further than this:
http://iocpsock.cvs.sourceforge.net/iocpsock/iocpsock/iocpsock_thrdpool.c?revision=1.2&view=markup
RegisterWaitForSingleObject is part of the system threadpool API that
exists in Win2K or greater. So even If I used it, I'd still need a
method for WinME, WinCE, etc..
What I'm saying is.. Let's share the job scheduler code, as that's the
most difficult part as I see it. Once you have a job scheduler waking
up Tcl with Tcl_AlertNotifer, the guts of reading and writing aren't
that difficult.
- --
David Gravereaux <davy...@pobox.com>
[species:human; planet:earth,milkyway(western spiral arm),alpha sector]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFFGBMolZadkQh/RmERAjP9AJ92kW/Iy3a5bza1BLX9yhYPL97kPQCffepY
OaMcevv4sp/9oRl1cpHeukI=
=0vlv
-----END PGP SIGNATURE-----
/Ashok
David Gravereaux wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>