Nächstes: Softwareentwicklung Nach oben: Aufbau Vorheriges: Modulare Mehrschicht

Beispiele zur modularen Mehrschicht

1a) Kindprozeß und exec (synchron)

 

Beispiel  (Abbildung 3.2):  

set myresult \
 [exec cmd args 2>@ stderr]

  
Abbildung 3.2: Quellentextbeispiel: Kindprozeß und exec (synchron)

Liefert insbesondere ein schnelles kurzes Ergebnis (Sperren (engl.:  ,,blocking``), Speicher (engl.:  ,,memory``)).  
 

Pro:

sehr übersichtlich

verbreitet unter Unix 

Contra:

synchron, Sperren (engl.:  ,,blocking``)

keine engen Schleifen (,,Unkosten`` durch fork()  (engl.:  ,,fork overhead``))

nicht alle Betriebssysteme

1b) Kindprozeß und exec (asynchron)

 

Beispiel  (Abbildung 3.3):  

set mypid \
 [exec cmd args 2>@ stderr &]

  
Abbildung 3.3: Quellentextbeispiel: Kindprozeß und exec (asynchron)

Dies kann insbesondere bei einmaligen Aktionen eingesetzt werden, bei denen der weitere Status nicht weiter relevant ist, beispielsweise in Bezug auf  MIME  verknüpfte Anwendungen.

Pro:

asynchron, Ereignisse , z.B. Signale

Contra:

kein exit Status, kein Rückgabewert

kein Terminierungssignal

2) Kindprozeß und fileevent (channel)

 

Beispiel  (Abbildung 3.4):  

proc was {arg} {
  global jobFinished
  puts "Still at $arg"
    if {![eof $arg]} {
        gets $arg data
      if [eof $arg] {
          set jobFinished 1
          catch {close $arg}
          puts "EOF reached"
          return
    }}}

set f [open "|calc " r]
fconfigure $f
 -buffering none -blocking no
fileevent $f readable "was $f"
vwait jobFinished
exit

  
Abbildung 3.4: Quellentextbeispiel: Kindprozeß und fileevent (channel)

Fileevents sind sehr universell einsetzbar, z.B. bei verteilten Architekturen.

Pro:

asynchron

volle Eingabe/Ausgabe (engl.:  ,,full I/O``) mit "r+" open

Kindprozeß lebt nur solange benötigt

Signal bei stdout close

volle exit Rückgabewerte (z.B. via catch {close})

flexibel (Sockets, Befehls-Weiterleitungen (engl.:  ,,named pipes``), ptys)

Integration durch vwait mit after Handlern und GUI

Contra:

 IPC  und Unkosten bei der Syntaxanalyse (engl.:  ,,parsing overhead``)

keine Befehls-Weiterleitungen (engl.:  ,,pipes``) auf bestimmten Betriebssystemen

3) Ladbare Erweiterungen

 

Beispiel (Abbildung 3.5):  

load my.so
myCall myargs ...

  
Abbildung 3.5: Quellentextbeispiel: Ladbare Erweiterungen

Die betrifft vor allem Erweiterungen, die z.B. über  IPC  und vergleichbare Mechanismen hinausgehen.

Pro:

sehr schnell

kristallklare API

auch nicht-Tcl Erweiterungen auf Win32

Contra:

nicht asynchron

Pflege (Verzeichnisse, Versionen, Namensgebung, ...)

 

4) Angepaßtes main() ...

 

Beispiel  (Abbildung 3.6):  

<main.c>:
...
Tcl_CreateCommand(...) ...

cc ... -lmylib -ltcl

  
Abbildung 3.6: Quellentextbeispiel: Angepaßtes main()

Statische Ergänzungen sind nur selten sinnvoll, werden aber gelegentlich aufgrund von Performanz, Entwurf und Vermarktung gewählt.

Pro:

einzige Lösung für statische firmeneigene Teile (z.B. engl.:  ,,legacy code``)

einfaches Packen in Binärform

Contra:

Komplexität steigt stark bei orthogonalen Erweiterungen

Tcl/Tk muß ebenfalls verfügbar sein

Nächstes: Softwareentwicklung Nach oben: Aufbau Vorheriges: Modulare Mehrschicht