Re: [Chicken-users] 4.7.3 development snapshot

[Jörg F . Wittenberger]

On Aug 23 2011, Felix wrote:

> > There is one more "strange observation":
> >
> > A small snipped of code, which happend to work for several years:
> >
> > (define (tcp-get-next-client tcpl)
> >  (##sys#check-structure tcpl 'tcp-listener)
> >  (let ((fd (##sys#slot tcpl 1))
> >         (tma (tcp-accept-timeout)))
> >
> > short after the "tma" is passed to ##sys#thread-block-for-timeout!
> > if - any only if - tma != #f.  In practice it is #f.
> >
> > Compiled with the 4.7.3 the code branch for tma != #f was suddenly
> > executed. Strange however: as soon as I wraped the call
> > (tcp-accept-timeout) into my usual "(debug label value)" [which sends
> > the label and value to the logfile and returns the value] I saw the
> > correct #f in the logfile and everything worked again.
>
> I think the code that does the test is what's of interest here.
> Can you show it to us?

Yes we can! ;-)

For better or worse I guess you need the full file (and maybe more?).

You will certainly find that the code could be written better for chicken. 
That's because it's a port from an rscheme version. (Just renamed lolevel 
things to chicken's counterparts - or merged them inline for whatever 
reasons I had at that time.) In fact I'd welcome suggestion; maybe I could 
get rid of that ##net#select? I'm pretty sure that the normal blocking 
mechanism could be used instead, could it?

What does it?  Open a network socket, accept connection, pass the file
descriptor to a subprocess (a C programm, which implements SSL/TLS via
openssl or gnutls and socks4a (for the sake of tor)), then it talks
cleartext to the subprocess via two pipes.

The issue however happens almost right at the code entry in the procedure
get-next-client.  See the second "strange 4.7.3 chicken" comment.

Best regards

/Jörg
...........

sslsocket.scm
Description: sslsocket.scm