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.

AMG: Recent Tcl (8.5+, I think) has arbitrary precision built-in for all integers.

• Does Tcl use 32 bit or 64 bit internal time representations? How much code needs to change to make use of a wider time_t value?

AMG: I'm pretty sure timekeeping got improved along with bignums, but I can't be certain.

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

AMG: Use Critcl to optimize the hotspots.

• What happens in Tcl when there is no more memory that malloc can allocate?

AMG: The same thing that happens in any other environment... right? malloc fails, program panics. Due to virtual memory, in most practical cases the system will become unusable due to thrashing long before malloc stops working. Page faults are normally transparent to applications, so there's nothing they can do about them in real-time. Programs just have to be designed to minimize them in the first place.

• What happens in Tcl when there are no more threads that can be allocated?

AMG: I doubt any serious Tcl program has ever hit this particular limit. Tcl needs threads far less than other development environments.

• What happens in Tk when there are no more Window IDs to be allocated, or they wrap around and begin to reuse ids?

AMG: Does Tk consume operating system/display system window IDs, or does it handle most or all of its drawing internally?

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.

DKF: We have been (slowly) working on improving Tcl and Tk to use [attemptckalloc] instead of ckalloc for large allocations so that failures we can conceivably recover from are non-fatal. However it's very difficult, as often memory is allocated in situations where there is no way to report an error and no way to continue without the memory asked for.

---