home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / unix / volume27 / distributed-c-2.1 / part06 / NOTES
Text File  |  1993-12-22  |  7KB  |  155 lines
  1.               Distributed C Development Environment - Notes
  2.               =============================================
  3.  
  4. 1.) Generating executable load modules:
  5. ---------------------------------------
  6.  
  7. You MUST use the same compiler for generating the runtime library functions
  8. and for generating the executable load modules to which these library functions
  9. are linked.
  10.  
  11. 2.) Problems encoding/decoding data (heterogeneous version only):
  12. ----------------------------------------------------------------
  13.  
  14. For interprocess communications between different machine types data must be 
  15. converted. This conversion is performed by encoding the data before sending 
  16. and decoding data after receiving using the Sun XDR-Routines.
  17. The encode and decode actions are performed via a dynamic allocated
  18. buffer '_dcc_buf', the size of the buffer is specified at runtime by the
  19. variable '_dcc_buf_size' in the corresponding source code of each process.
  20. But the size needed to encode/decode dynamic structures like trees
  21. or lists can not be predicted at compilation time correctly!
  22. Because of that, there are two different ways for generating code.
  23. The default action performed by the compiler is to generate code which
  24. determines the size of the buffer as the size of the greatest structure
  25. to fit in multiplied by 4. If dynamic structures are used, it is better 
  26. to specify a sufficent size using the '-f <bufsize>' compiler option.
  27. If the allocated buffer size is too little to convert the dynamic data
  28. structures, errors during encoding/decoding will be the consequence up to
  29. process crashes. So if you get runtime errors like "error encoding data"
  30. or "error decoding data" you may probably be able to fix this problem by 
  31. inctreasing the size of the corresponding variable '_dcc_buf_size'.
  32.  
  33. Many errors during encoding and decoding data are the consequence of
  34. wrong pointer handling caused by the programmer. 
  35. Consider this aspect if you get encode/decode errors!
  36.  
  37. 3.) Problems using 'stdin', 'stdout' or 'stderr' (heterogeneous version only):
  38. -----------------------------------------------------------------------------
  39.  
  40. You will get problems, if you use 'stdin', 'stdout' or 'stderr' in Distributed
  41. C programs and compile the generated standard C source code files via remote
  42. compilation on different machines.
  43. The problem is caused by the different definitions at the various machines.
  44. For example at a CONVEX 'stdin' is defined in 'stdio.h' as "(&__ap$iob[0])",
  45. at a Sun Sparc Station as "(&_iob[0])", and at a Hewlett Packard Workstation
  46. as "(&__iob[0])".
  47. To avoid this problem you have easely to write the following code at the
  48. beginning of your Distributed C programs right after the include-directive,
  49. which includes the file 'stdio.h':
  50.  
  51.     #include <stdio.h>
  52.     #undef stdin
  53.     #undef stdout
  54.     #undef stderr
  55.  
  56. This will cause warnings of the type "xxx redefined", which can be ignored.
  57.     
  58. 4.) Termination of all created processes after errors:
  59. ------------------------------------------------------
  60.  
  61. If you want to shut down all created processes of an executing parallel program
  62. after errors, you can do this be calling the system function abort() in the 
  63. process which detected the error.
  64.  
  65. 5.) Manually termination of all created processes:
  66. --------------------------------------------------
  67.  
  68. If you want to terminate all generated processes of an executing parallel 
  69. program manually, send signal SIGTERM to the corresponding administration 
  70. process dcadmin. Sending signal SIGTERM to dcadmin during runtime will cause 
  71. the forcefully termination of all generated processes.
  72.  
  73. 6.) Nested Distributed C statements:
  74. ------------------------------------
  75.  
  76. You can't nest Distributed C Statements at will.
  77. Do NOT use accept- or create-statements within accept-statements, because
  78. this will cause an runtime error in the communication primitives.
  79.  
  80. 7.) Automatic process to node allocation:
  81. -----------------------------------------
  82.  
  83. You can use the process to node allocation performed by the informations of
  84. a program and a system configuration file only for the HOMOGENEOUS or 
  85. HETEROGENEOUS version of the compiler. 
  86. Be careful not to use it at the Intel Hypercube: define USE_MAPFILE during
  87. compilation of the administration process for the iPSC compiler version.
  88.  
  89. 8.) Problems with system include files:
  90. ---------------------------------------
  91.  
  92. Any system files '#include' directives (e.g. "stdio.h") of a Distributed C 
  93. program are collected and written to the corresponding generated include file.
  94. If you use "#include <xxxxx.h>" preprocessor commands in combination with the
  95. '-Ipath' option during preprocessing, the problem may occur that this include
  96. directive does not appear in the generated include file.
  97. The reason is that only the paths '/usr/include' and '/usr/local/dist/include'
  98. are currently considered to be directories for storing system include files.
  99. If you get the problem that some include files which are located in special
  100. paths and are included with "#include <....>" in combination with '-Ipath', you
  101. must add this path to the already considered paths ("/usr/include", ...) in the
  102. files dcc/includefile.c and dcc/yyfuncts.c.
  103.  
  104. 9.) Supported operating-system/machine/environment configurations:
  105. ------------------------------------------------------------------
  106.  
  107. Following is a list of systems on which the software package was successfully
  108. used. The list elements have the structure 
  109.   operating system, operating system version, 
  110.   machine types, 
  111.   communication routines, supported network types:
  112.  
  113. o AIX, 3.2, 
  114.   RS 6000, 
  115.   SOCKET, HETEROGENEOUS
  116. o ConvexOS, 10.2, 
  117.   C220/C3840, 
  118.   SOCKET, HETEROGENEOUS
  119. o HP-UX, A.09.01, 
  120.   HP9000-720/HP9000-755, 
  121.   SOCKET, HOMOGENEOUS/HETEROGENEOUS
  122. o Linux, 0.99.13, 
  123.   AT i486s, 
  124.   SOCKET, HOMOGENEOUS
  125. o SCO Xenix, 2.3, 
  126.   AT i386, 
  127.   MSGSEM, SINGLE
  128. o SCO Unix, 3.2, 
  129.   AT i386, 
  130.   MSGSEM, SINGLE
  131. o SunOS, 4.1 or greater, 
  132.   Sun SPARCstations(sun4c),
  133.   SOCKET, HOMOGENEOUS/HETEROGENEOUS
  134. o Ultrix, 3.1, 
  135.   DECstations,
  136.   SOCKET, HOMOGENEOUS
  137. o Unicos, 7.0, 
  138.   Cray Y-MP, 
  139.   SOCKET, HETEROGENEOUS
  140.  
  141. (SOCKET = TCP/IP data stream sockets, MSGSEM = message queues and semaphores)
  142.  
  143. 10.) Problems starting Distributed C programs on Linux systems:
  144. --------------------------------------------------------------
  145.  
  146. Use sockets as communication primitives on Linux systems!
  147.  
  148. If you still get problems starting Distributed C programs on your Linux system,
  149. check if your network is correctly configured. You have to configure your 
  150. Ethernet card if your system is connected to a network. If your machine is a 
  151. standalone system you MUST configure the 'loopback mode' (i.e. no SLIP, no 
  152. ethernet card, just TCP/IP connections to your own machine---called "loopback",
  153. IP address 127.0.0.1) to be able to run Distributed C programs (to do so, see 
  154. the corresponding FAQs, especially 'NET-2-HOWTO').
  155.