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

[Camm Maguire]

Greetings!

Michael Koehne <address@hidden> writes:

> 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.
> 

Yes, we had an older thread on server sockets.  Many things are
straightforward to implement, we just need a plan.  The earlier
consensus appeared to prefer select to SIGIO and/or fork.  cmucl does
all its i/o through select -- I doubt we'd want to be this radical.
Barring this, the user would have to run select when they wanted to.
Doesn't seem so nice.  In any case, we first need a specific well
drafted proposal we can all agree on.  We have to figure out what to
do with windows.  And we have to figure out how to link in ssl without
making everyone depend on it.  

As this is not part of the ansi spec, I personally put this as a lower
priority.  Stuff that is not in the spec should be autoloadable
modules in any case IMHO.

Take care,

> Bye Michael
> -- 
>   mailto:address@hidden             UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
>   http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah