Forwarded from: marcov@stack.nl (Marco van de Voort)
(Sorry, it's a bit late. I had overlooked it.)
On 2006-02-25, Frank Heckenbach ih8mj@fjf.gnu.de wrote:
However, as I've said before, I'm skeptical about Input etc. Do we really want a per-thread Input, each with its own buffer (which means, if several of them are acutally used, it becomes hard to foretell in which one each sequence of input bytes ends up)? Similar for Output. For StdErr, one could argue that it shouldn't buffer at all (which GPC's in fact doesn't, and so does stderr in C by default AFAIK).
This is a possible problem, buffering also complicates initialisation of a new thread, because it requires more than a shallow copy of the threadvar segment. (buffer is duplicated, stuff in output is thus twice in buffer, not to speak about what if you use pointers in the filedescriptor record etc).
There are bugreports about problems with threadsafe input/output in FPC bugrepository, mostly in combination with unit crt.
There's a few more in TP-compatibility units (like doserror in the Dos unit and some crt things)
Well, for CRT, just making the internal state per-thread wouldn't really help much AFAICS. E.g., if each threads has its own screen buffer, and updates the real screen from it, this would probably result in chaos. IOW, as there's only one physical screen (unless multi-headed), I think one probably needs some common data across threads. Or you leave it up to the user -- as, e.g., ncurses recommends doing all curses I/O within one thread.
The latter thing is a typical thing for UIs. E.g. Delphi also specifies the VCL (GUI classes) as non-threadsafe. It provides a synchronization mechanism though to schedule basic code in the mainthread.
Since our RTL is under a slightly modified LGPL (allows static linking as long as you make the modifications to the FPC-RTL-licensed code available), license-wise I don't think there is any problem for you to reuse things. If there is, we could dual-license it under the regular LGPL as well I suppose (the main reason for the static linking exception is that some OS'es, like Dos, simply do not support dynamic linking, and support for creating dynamic libraries was not available for all OS'es in our compiler from the start either).
BTW, standard LGPL allows static linking as well. You just have to distribute object files of the non-free parts, so users can relink. But I suppose for some reason that's not desired?
No. I think we simply didn't think of that, and the GNU site didn't spell it out either. It is a good point for the license FAQ though.