Version 4 of When should Tcl/Tk/etc. NOT be used

Updated 2003-06-08 08:52:03

Purpose: to discuss the seamier side of Tcl.

What are the situations where use of Tcl may not be the best fit? What types of applications are better suited in some other language? What types of limitations does Tcl have intrinsically that should be considered when evaluating it as a part of an application solution?

  • Does Tcl use 32 bit or 64 bit numeric values? Is it a simple matter to make use of 64 bit options? There is always mpexpr as an arbitrary precision expr extension.
  • Does Tcl use 32 bit or 64 bit internal time respresentations? How much code needs to change to make use of a wider time_t value?
  • Number crunching in pure Tcl is probably not the best idea - it tends to be a bit slow. However, there's no reason you couldn't do the crunching in another language and link it in, or use a computer server and then Tcl/Tk as an interface that communicates with that server.

FW: Number crunching in any scripting language is slow. Tcl is only slightly below the standard in this case.

  • What happens in Tcl when there is no more memory that malloc can allocate?
  • What happens in Tcl when there are no more threads that can be allocated?
  • What happens in Tk when there are no more Window IDs to be allocated, or they wrap around and begin to reuse ids?

Please add either your own questions, answers, or other problems you have found. This is NOT intended as a place to bash Tcl. Instead, in many of these cases, people have found work arounds for the problems, patches, extensions, etc. and so let's collect them here.

Jeffrey Hobbs suggests: Include in your WiKi page the use of Tcl_SetPanicProc. True, by default Tcl will panic on a failed alloc (it doesn't just crap out, I didn't reread the earlier problem, but you should always use ckalloc with Tcl), but this panic can be overwritten by your own magic command (it already is on Windows). The way to overcome a low mem situation would be to prealloc your X MB buffer, wait until you come to the panic, free that buffer and exit "cleanly". There is no other way around it, and I don't know of any other popular language that handles it in a better way. Hmmm, you know, it wouldn't be more than a couple dozen lines of C to make an extension that creates a Tcl proc that overrides the panic and calls a Tcl level procedure (for what it's worth)....

Joe Mistachkin -- 8/Jun/2003: This touches on part of the rationale for TIP #121. It is not always desirable or appropriate to just call the C-runtime exit() or abort() in a complex multi-threaded application which may be involved in any number of "critical" processes. The "application" could be part of a much larger system. In this case, Tcl/Tk is the "scripting engine" for the application. This is important to keep in mind because Tcl/Tk was originally designed to perform primarily in this capacity.