Re: [Gcl-devel] Re: gcl_signal & sockets

[Michael Koehne]

Moin Camm Maguire,

> Test conditions for the signal handlers would be very useful in
> reverse engineering the intent.  In particular, the handling
> possibilities of SIGALRM and SIGIO could have implications for a
> possible (re-)implementation of server sockets in gcl.

  I dont want to bombard a gcl-tk with sigusr1 ;( I can see some race
  conditions without ;) My idea on signal and sockets would be :

  - I've already implemented read-sequence/write-sequence for postgres
    interface, and I'm currently patching on pretty printer to get f2cl
    up and running.
  - next could be a deeper look into o/file.d to implement 3 things :
    - white streams (old GCL streams)
    - black streams (file/socket streams operating of file descriptors
      instead of using stdio or readline to operate on file pointers)
    - interface for Gray streams (user defined streams of mostly
      Common Lisp manner)

  this would allow to refactor gcl-tk to get rid of the sigusr1 signal,
  because events are now triggered by the streams/socket/select/idle
  loop. This loop needs some way to register additonal co-routines,
  e.g. for updating OpenGL. Idea would be to have some GCL, that is
  able to act as a socket server and X11/OpenGL client at the same
  time, without the need to add any C code.

Bye Michael
-- 
  mailto:address@hidden             UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
  http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM