[Gcl-devel] Re: GCL-TK on Windows

[Camm Maguire]

Greetings!

Mike Thomas <address@hidden> writes:

> Hi Camm.
> 
> Some work done - notably cleaning up the Windows GCL-TK config,
> inserting some preliminary code to pretend about sigusr1 and fixing a
> Windows only TCL/TK initialisation bug; but heaps to go.
> 

Great!  Thank you so much!  Any word on how Tim is doing with the
axiom gcl-tk interface?  In any case, as soon as we get this going, I
think 2.6.7 is ready.

> The sticking point at the moment is as follows:
> 
> By launching gcltkaux in gdb I find that executing connect in
> sock_connect_to_name () in guis.c causes GCL to immediately return
> from SYSTEM:ACCEPT-SOCKET-CONNECTION, sending the
> 
> "source c:/cvs/head/gcl/gcl-tk/gcl.tcl"
> 
> command to the server and causing an error in GCL before gcltkaux even
> gets to check the result returned by connect (), ie well before
> running TkX_Wish ():
> 
> =======================================================================
> c:\cvs\head\gcl\gcl-tk>start gdb --args
> c:/cvs/head/gcl/gcl-tk/gcltkaux 127.0.0.1 5016 2020
> 
>      2> (SYSTEM:ACCEPT-SOCKET-CONNECTION (880 . 5016))
>      <2 (SYSTEM:ACCEPT-SOCKET-CONNECTION
>             (("P♥                       └⌂→     └⌂→     ►  ╕♂  "
>               . "127.0.0.1")
>              880 . 5016))
>      2> (TK::TK-CONC "source " "c:/cvs/head/gcl/gcl-tk/gcl.tcl")
>      <2 (TK::TK-CONC "source c:/cvs/head/gcl/gcl-tk/gcl.tcl")
>      2> (TK::TK-DO "source c:/cvs/head/gcl/gcl-tk/gcl.tcl")
> grab-tk-command           , fill pointer 10
> with-tk-command
>        3> (TK::CALL-WITH-RESULT-TYPE
>               "          source c:/cvs/head/gcl/gcl-tk/gcl.tcl" STRING)
>          4> (SYSTEM:OUR-WRITE
>                 "P♥                       └⌂→     └⌂→     ►  ╕♂  "
>                 "♠A♣ &     source c:/cvs/head/gcl/gcl-tk/gcl.tcl " 48)
> Error in SYSTEM::TRACE-CALL [or a callee]: Connect failure: ""
> 
> Fast links are on: do (use-fast-links nil) for debugging
> Broken at SYSTEM:OUR-WRITE.  Type :H for Help.
>   1 (Continue) Return to top level.
> dbl:>>
> 
> =======================================================================
> 
> Looking at the last few lines of tk::tkconnect:
> 
> =======================================================================
>        ...
>        (if (eql pid -1)
>         (si::SET-SIGIO-FOR-FD  (car (car *tk-connection*))))
>        (setf *sigusr1* nil)
>        (tk-do (tk-conc "source " (namestring
>               (merge-pathnames "gcl-tk/gcl.tcl" si::*lib-directory*)) )))))
> =======================================================================
> 
> I see that if pid = -1, SIGIO (whatever that is) should be set for the
> fd - on my computer this doesn't happen as pid is not -1 (not that
> SIGIO means anything and I have doubts that one could attach GCL's
> fake signal system to a C runtime fd anyway).
> 
> Then *sigusr1* is set to nil and tk-do is called on the TCL command to
> source "gcl.tcl".

SIGIO (kernel signals for io pending) is not set on Linux either, and
*sigusr1* is nil.  I think this is your problem:

   { int n = write(sfd->fd,buf,n_to_send);
     if (n == n_to_send);
     else   if (n < 0)
       {  if (errno == EAGAIN)
            { goto AGAIN;
            }
       else connection_failure("");
          }
     else abort();
   }

You have to make sure the socket is setup to set errno (or equivalent)
to EAGAIN when the socket is not ready for writing.  On Linux, this is
done with O_NONBLOCK to fcntl or similar.  There are several options
in nsocket.c/sockets.c, e.g. set-blocking.  Apparently Linux uses
blocking, but the timing appears to work out.

Please let me know if problems persist.

Take care,


> 
> This appears to lead ultimately to write1 () in comm.c without any
> pauses based on *sigusr1* - I must have missed something (it's getting
> late) as I expected somewhere in here to see code which causes the
> write1 to hold off until gcltkaux is actually ready to receieve, but I
> am not seeing such a mechanism (unless, of course, the SIGIO thing was
> really supposed to happen - but I don't understand how GCL could
> acquire a PID of -1 here either).
> 
> Have you any advice?
> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 
> 

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