On 09/25/2013 11:26 AM, Michael Schnell wrote:
On 09/24/2013 10:58 AM, Nikolay Nikolov wrote:
When you try to create a thread, your program terminates and writes a
message that threading is not supported.
While this absolutely does make sense, one could think about
alternatives.
AFAIK, (at least for some archs) there is a variant of the pthread
(="POSIX thread") library, that internally does "user-land
multithreading". IIRC, the original POSIX definition was done with
exactly this in mind and, regarding Linux, the original Linux
implementations (aka "Linux Threads") was not fully compatible with
POSIX. Only some years ago, the Linux changed it's way of Kernel-based
thread handling to the POSIX compatible "NPTL" implementation.
Thus it should be possible to link fpc projects to a user-land thread
enabled version of pthreadlib and allow for working with TThread in DOS.
I've actually thought about implementing some sort of multithreading for
DOS for a long time. The problems are the following:
1) DOS functions are not reetrant and are thus not safe to call from
different threads. There's an undocumented InDOS flag that indicates
whether a DOS function is safe to call:
http://stanislavs.org/helppc/int_21-34.html
But the RTL currently doesn't check it before every call and normally
it's only used when writing TSRs.
2) In DPMI protected mode applications (such as go32v2), you cannot
modify the return address from within an interrupt handler, which means
you cannot implement your task scheduler as a timer interrupt handler,
because you won't be able to switch to a different context from there.
Doing this would require modifications to the DPMI host (cwsdpmi.exe)
and will not work if another DPMI host is active (such as when running
in a windows dos prompt, etc.)
3) Even if you solve 2), DPMI requires that all code and data touched
from an interrupt handler to be locked, so that it cannot be swapped
out. This is a tedious and error prone task to do from a high level
language such as pascal. You should ensure that your entire scheduler's
code and data are locked. An alternative option is to switch to a DPMI
host, that doesn't support swapping (i.e. cwsdpr0.exe), but then you
lose the virtual memory support (and thus the ability to run on machines
that don't have enough memory).
2) and 3) do not apply to 16-bit MS-DOS.
Another option is to implement cooperative multitasking, which would
require each thread to call periodically an yield function. This solves
1), 2) and 3), but threaded code written for other OSes will require
modifications to run under DOS. However, that's still better than not
running at all.
Nikolay
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
