hot@integow.uucp (Roland van Hout) (04/19/91)
We are UNIX C programmers. We have the possibility to port some of our
applications to OS/2 for a client. Is it possible to compile reentrant
C programs to save memory or must we implement threads to simulate
this capability.
--
UUCP: ..!uunet!mcsun!hp4nl!integow!hot or hot@integow.UUCP
Roland van Hout, Sr. software engineer, Integrity software consultants,
Pelmolenlaan 2, 3447 GW Woerden, Netherlands,
tel +31 3480-30131, fax +31 3480-30182ballard@cheddar.ucs.ubc.ca (Alan Ballard) (04/21/91)
In article <1581@integow.uucp> hot@integow.uucp (Roland van Hout) writes: > >We are UNIX C programmers. We have the possibility to port some of our >applications to OS/2 for a client. Is it possible to compile reentrant >C programs to save memory or must we implement threads to simulate >this capability. 1) All OS/2 code is reentrant. If you are run more than one copy of the program, only one copy of the code is loaded. 2) If you want to share code among different applications, you create "dynamic link libraries" containing the code. 3) Even if you did need to use threads, you don't need to implement them. OS/2 has built-in threads. OS/2 does all this stuff much better than unix. Alan Ballard | Internet: ballard@ucs.ubc.ca University Computing Services | Bitnet: USERAB1@UBCMTSG University of British Columbia | Phone: 604-822-3074 Vancouver B.C. Canada V6R 1Z2 | Fax: 604-822-5116
d9mikael@dtek.chalmers.se (Mikael Wahlgren) (04/21/91)
In article <1991Apr20.190744.6675@unixg.ubc.ca> ballard@cheddar.ucs.ubc.ca (Alan Ballard) writes: >1) All OS/2 code is reentrant. If you are run more than one copy of the > program, only one copy of the code is loaded. Note that some C-libraries are NOT reentrant. Mikael Wahlgren d9mikael@dtek.chalmers.se
ballard@cheddar.ucs.ubc.ca (Alan Ballard) (04/22/91)
In article <1991Apr21.083505.22743@mathrt0.math.chalmers.se> d9mikael@dtek.chalmers.se (Mikael Wahlgren) writes: > >Note that some C-libraries are NOT reentrant. > All the C libraries handle reentrancy across processes, as far as I know (they have "instance data" allocated for each process). However, it is possible to have problems with multiple threads because there isn't a separate copy of this data for each thread. For example, a static I/O buffer can cause problems if two threadsin the same process do I/O. There is a multi-thread version of the standard library to deal with this. Alan Ballard | Internet: ballard@ucs.ubc.ca University Computing Services | Bitnet: USERAB1@UBCMTSG University of British Columbia | Phone: 604-822-3074 Vancouver B.C. Canada V6R 1Z2 | Fax: 604-822-5116
bking@nro.cs.athabascau.ca (Barry King) (04/22/91)
ballard@cheddar.ucs.ubc.ca (Alan Ballard) writes: > In article <1581@integow.uucp> hot@integow.uucp (Roland van Hout) writes: > > > >We are UNIX C programmers. We have the possibility to port some of our > >applications to OS/2 for a client. Is it possible to compile reentrant > >C programs to save memory or must we implement threads to simulate > >this capability. > 1) All OS/2 code is reentrant. If you are run more than one copy of the > program, only one copy of the code is loaded. > 2) If you want to share code among different applications, you create > "dynamic link libraries" containing the code. > 3) Even if you did need to use threads, you don't need to implement them. > OS/2 has built-in threads. > OS/2 does all this stuff much better than unix. > Whoa. When you say that all OS/2 code is reentrant, that may be true for the operating system, but this is _definitely_ not true for applications programs. Hence the requirement for reentrant libraries like MSC LLIBCMT.LIB and the deficiency in Zortech's C++ compiler that does not support reentrant code. Running more than one copy of the program is one thing but the code within a given running program is not gauranteed to be reentrant unless you code it as such. Same with DLLs - they'll have to be coded to be reentrant with appropriate libraries. OS/2 of course has 'built in' threads - each process is at least one thread under the PM. Within an application, it is the programmer who determines what runs under separate threads. I'm sure you know this, Allan, but for the benefit of the poster of the message to which you replied, I think some clarification is necessary. I found your reply somewhat misleading. Regards! Barry King ersys!bking@nro.cs.athabascau.ca Edmonton Remote Systems: Serving Northern Alberta since 1982