Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Best way to add support for named pipes on Windows ?

29 views
Skip to first unread message

pal...@yahoo.com

unread,
Sep 25, 2006, 2:28:59 AM9/25/06
to
Is there any support in the core or through an extension to be able to
use named pipes as channels on Windows? A web search did not turn up
anything useful.

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

David Gravereaux

unread,
Sep 25, 2006, 1:34:32 PM9/25/06
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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-----

pal...@yahoo.com

unread,
Sep 26, 2006, 11:42:43 PM9/26/06
to
David, thanks for the pointers. I went and read up on Tcl channels and
MSDN links for the functions you suggested. It looks like a lot more
work than I'd thought it would be. It'll have to stay on TWAPI's
backburner for the moment given the other stuff I've to get done (and
I've never seen anyone ask about named pipes on Windows so it's not
exactly high priority)

/Ashok

David Gravereaux wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

0 new messages