Forwarded from: marcov(a)stack.nl (Marco van de Voort)
(Sorry, it's a bit late. I had overlooked it.)
On 2006-02-25, Frank Heckenbach <ih8mj(a)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.
