Mail Archives: djgpp/2000/01/26/02:57:13
Gautier (gautier DOT demontmollin AT maths DOT unine DOT ch) wrote:
: > Don't forget that Ada uses an entirely differen library, so this is not
: > really relevant to the issue (non-reentrancy of some DJGPP library
: > functions).
: Are you sure ? In the GNAT system, the Ada tasks are mapped to the available
: thread library (after GNAT Reference Manual http://lglwww.epfl.ch/Ada/gnat_rm.html
: or http://search.metacrawler.com/crawler?general=GNAT+Reference+Manual)
: and surely inheritate the same reentrancy issues on DJGPP (not tested)...
: Runtime in (more) commercial Ada's have their own tasking system for DOS
: (or DOS extender) with sheduler etc. for mapping the Ada task to.
: But doesn't the original poster just want to build them from sources - before
: using them I mean - ?...
Hum, I'm not a DOS experts. Getting some sort of threading for DOS
and DJGPP should not be hard if you can set a timer with setjmp/longjmp.
But there are other things involve.
thread-safe: meaning multiple threads can enter a function/code
without any destructive side effects are race conditions.
DJGPP C lib is not thread safe, it does not provide the necessary
hooks(mutex, lock, sync) to make threads enter the same function safely.
The lib makes use of static and globals variables, mind you it may
not be as bas as first glimpse showed.
reentrancy: system calls, the same buffer is use for all systems. So
if one thread does, let say a read() and the otherone a readdir()
they may intertwine, or something like that I was told.
There are many ways to go around this :
- having a buffer per thread (TLS)
- serializing the system calls
- use threads only for computations.
...
etc ..
and the C lib needs to be made thread safe, or you make sure
after carefull review that your threads do not access the C functions
that are not thread safe. Or provide a jacket/wrapper that would
serialize the C func you consider not thread-safe.
Now the question is, is it worth the trouble to put some of that work
in the DJGPP C lib ? dunno. Because sometimes thread safeness comes
with high price tag .. speed, efficientcy, complexity. For example if
putc() and getc() has to be made thread safe and for doing this the
usual approach is to grab a lock and unlock at the end.
Now in simple programs like this :
for (;;) { ... getc (); ... } /* fast loop */
This is a killer, the overhead is significant. Fortunately POSIX
defines functions like getc_unlock() and putc_unlock() for this.
But not everyone is thread saavy, so the FAQ volume quadruple.
There are people in this newsgroup strugling from DOS --> Un*x. Now
imagine having to deal with Thread too ... I don't know if the
advantage will be visible.
--
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!
- Raw text -