[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another 4.0 problem!
From: |
Jan-Henrik Haukeland |
Subject: |
Re: Another 4.0 problem! |
Date: |
Thu, 18 Sep 2003 21:05:49 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux) |
Jan-Henrik Haukeland <address@hidden> writes:
> Aha, damnit, I just browsed through processor.c and I can see that
> we are using standard file i/o via a FILE variable. Using a
> buffering FILE is a sure reciept for disaster when non-blocking i/o
> is used.
If the set unbuffered hack doesn't work then what we need to do is to
create a Socket_T from the accept call in engine.c put this Socket_T
in the request wrapper and use socket_read and socket_print instead of
fprintf. We will probably also need a socket_readln() method, here we
can use the gets_ssl_socket() template created by Christian. If we do
this can can also get rid of all the if(ssl)..else.. code in
processor.c
I can give it a stab if the unbuffered hack doesn't work, but I need
to know if it works or not, since I cannot reproduce the problem with
my small monitrc control file.
--
Jan-Henrik Haukeland