Perl has access to socket programming primitives. You can essentially do ''everything'' you can do in C (with often the same function names).

I had to do some hardcore (200+ 6KB UDP messages/sec across 6 sockets) networking. It had to run 24x7 and there was no room for memory leaks. Naturally I prototyped it in Tcl (plus TclX and the TclUDP extension).

But Tcl is slow. To satisfy a caching requirement, I queued the messages in a Tcl list and used Tclx's lvarpush and lvarpop to store/fetch the messages. That was an order of magnitude slower than the same algorithm in Perl (using push and shift on arrays).

Still, the Perl app wasn't any faster. ''The network is the bottleneck''. But, more interestingly, I had to implement some common Tcl idioms (involving fileevent, after and non-blocking/non-buffering puts) in Perl. And, that is where I learned how well thoughtout the Tcl I/O system was.

As a side note, I added a very slim "udp_read" C function to my app to compare it with going through the channel based Tcl read proc (as TclUDP does). Not much performance improvement was gained by doing that.

In the end, Perl did allow me to tweak a few more things (but I could easily do that with a couple of Tcl extensions). Perl networking is much richer (without having to go to C). However, after struggling with partial writes (using syswrite) and mucking with IO::Select to get it to act like the Tcl event loop, I've come to appreciate the things Tcl does for me.

The lesson learned: Perl has better low level networking access, but the Tcl code contains a lot of built-in idiomatic functionality that you'll find yourself hand-coding to duplicate in Perl (and to less effect). See [POE].

-- [Todd Coram]  ''Once again, it looks like my Tcl prototype will make it into production without the often obligatory C rewrite!''

''[jcw] - Imagine having the best of both world: a 1-to-1 mapping of C system calls to Tcl, with the event system coded in Tcl...''
It could tie in nicely with [a critical mindset about policy], and make such a Tcl system considerably more modular (package require sockets?).  It also means someone who needs UDP could add it in Tcl, and instantly have it work on all platforms with the same system call interface.  It would not rule out a more efficient C-coded implementation, it would just provide more choices and portability.

[DKF]: I think that's one of your less well-baked suggestions jcw.  :^)  The ''good'' thing about Tcl is that it hides all the crap.  Expose it, and many people will insist on using it (because they're mindlessly reading off how to do it in some out-of-date networking bible) no matter how much there are better APIs available.  And the main problem with [UDP] is that it doesn't fit with Tcl's channel abstraction; AKu's been looking into this.  (As always, external packages can do whatever they want.)

[Todd Coram] - Sometimes I need access to the crap. What I really want is a backdoor (without relying on the crutch of dropping down to coding C extensions everytime). Maybe a ''package require posix'' or ''package require tcp''? I think Tcl is too slow to efficiently manipulate a low level api. This isn't a criticism though. Most of the time I just need Tcl's high level of I/O abstraction. What I (probably) really need is fconfigure on steroids. Sometimes I need to tweak socket/TCP parameters... The problem with ''fitting'' UDP into the channel abstraction is that it isn't a natural fit. It's a forced fit. Just like unix making ''read(2)'' deal with UDP. UDP isn't a streaming protocol. The ''one unifying abstraction'' tries to force the ''one true way'' with abstracting a family of similiar facilities (which usually leaves the edge behaviors/neeeds unsatisfied).

[jcw] - (in response to Donal) - Point taken, and agree 100% on potential for abuse.  But I really would like to lobby for a more "systems scripting" kind of mindset.  We currently avoid the problem by using some obscure language with an even more obscure single-letter name to prevent mainstream application developers from messing with deep stuff.  Can't we get rid of this detour, have a core exposed to "inner Tcl", have a few systems-programmer type people design and build the next layer, and then call the result Tcl or Tcl NG or outer Tcl?  The current approach comes from the time when C was the center of the universe and Tcl a neat idea built on top.  Isn't it time to make C revolve around Tcl instead?  And ''optional''?  Today, we have a pretty unforgiving brick wall - if you want anything more than Tcl caters for, then you must dig C first and dig the Tcl C core second!  Yeah right, come back in a year when you're done... :)

There's also a different argument to be made: natural selection.  If a lower level core is exposed as Tcl building blocks, then a few more developers would be able to experiment and come up with say a UDP system (you have to be pretty experienced at this stuff to actually pull it off, so I think we won't be seeing dozens of competing solutions any day soon).  One of them is bound to hit the sweet spot between the channel model and events.  And that one could then be picked up and given a more prominent status, as *THE* udp package for Tcl.  Or re-implemented in C, if you insist.

[DKF] (responding to Todd): I'd love to see more [fconfigure] options for sockets, just as I would love to see support for UDP with a suitable messaging paradigm.  (And support for Unix-domain sockets too, while I'm at it!)  I just haven't got time to do the work to make it happen as my pay-work is pretty heavy going at the moment.  :^(

[DKF] (responding to jcw): Sounds really cool to me (like the vast majority of your ideas.)  It'd have to be a Tcl9 thing since you'd be requiring alterations to existing scripts that make use of sockets, but that's not too big a deal IMHO.

----
[Tcl Advocacy] |
[Category Internet]