On 2004.08.17, Stephen Deasey <[EMAIL PROTECTED]> wrote: > The performance difference would certainly be noticeable.
As long as we're clear that we're BOTH speculating here, then I'm okay with your statement. If you're asserting this to be true, where's the proof? > In your example code a new thread is spawned for each connection. This > can take a non trivial amount of time, especially if a new interp has to > be initialized. I could, inside 50 lines of code, implement my own thread pool in pure Tcl. I didn't need it, so I didn't bother. > Each of your connection threads and all it's resources are committed for > the life of the connection. It will remain committed until the client > disconnects. This will be true regardless of the implementation (C vs. Tcl) as it's a requirement of the TiVo beacon protocol -- clients maintain persistent connections to the server. > There are some functional differences too: no access logging; none of > the niceties of registered procs or filters; no caching of returned > files, etc. etc. Access logging would be easy to implement if the nslog module was extended to expose a Tcl command to generate log entries that nslog would write. Probably not a bad idea for an RFE. Registered procs and filters are irrelevant for my specific case, but again, an exposed Tcl command that allowed one to execute the procs or filters registered for a user-provided URL would make this possible with two lines of Tcl in my code. Caching of returned files -- in my case, the responses are fully dynamic. My point is, I'm implementing a non-HTTP server. Many of the features of AOLserver that make it an excellent choice as an HTTP server are irrelevant if you're not implementing an HTTP server. > None of which matters for a toy like a Tivo server. An SMTP or IMAP > server implemented like this wouldn't be worth the bother. I disagree. SMTP and IMAP are toy servers with regard to complexity, just as the TiVo server is. They are all very simple protocols. The challenge is scalability -- the assumption here is that a pure Tcl solution will not perform well enough to scale compared to the C solution. It's only an assumption. My hunch is that empirical evidence will show that none of the "features" of AOLserver will make the C solution perform exceptionally better than a pure Tcl solution. If you're going to implement in C for performance, implement something tailored to solving the problem specifically -- that will be the only way to really get the performance required. Of course, we're both only speculating here. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
