From: alain AT qnx DOT com (Alain Magloire) Newsgroups: comp.os.msdos.djgpp Subject: Re: posix threads with djgpp Date: 26 Jan 2000 03:07:52 GMT Organization: QNX Software Systems Lines: 63 Message-ID: <86loe8$kbv$1@gateway.qnx.com> References: <388DD4EA DOT E8925EBE AT maths DOT unine DOT ch> NNTP-Posting-Host: qnx.com X-Trace: gateway.qnx.com 948856072 20863 209.226.137.1 (26 Jan 2000 03:07:52 GMT) X-Complaints-To: usenet AT qnx DOT com NNTP-Posting-Date: 26 Jan 2000 03:07:52 GMT X-Newsreader: TIN [version 1.2 PL2] To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com 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 !!!