Sure, there's a better way.
If I remember right, here's the problem. Socket writes hang until there's
room in the socket buffer to stick the data. In this case, the problem
arises when the UI is writing a big collection of macro definitions and
variable assignments to the exec, notably the contents of a .net file. As
the exec digests these, it generates messages back to the UI.
Unfortunately, the UI wants to write the entire thing to the exec before
going back to process messages received from the exec. The exec fills its
output buffer, and ceases reading input while it waits for the UI to do a
read() on the socket, freeing buffer space. Unfortunately, the UI keeps on
writing to the socket, expecting the exec to be reading. When the UI's
output buffer fills, the UI's write hangs, and each is waiting for the
other to read something.
The problem may very well occur in the opposite direction as well.
It seems to me that one way to fix this would be to use a non-blocking
socket. Then, whenever a write is done to the socket, the return code
could be examined to see if it would have blocked. If so, it would then go
read off the input socket before going back to try again.
The only thing that I worry about is that this would alter the sequence in
which messages are written and read. This might have bad ramifications,
FAIK, and would be very difficult to test fully. Alternately, the we could
read the input and buffer it ourselves. Then, when it would normally read
from the input, it would first check to see if there's already input
buffered before going to try the socket. That might be easier to test.
Any volunteers?
Greg
Mattijs Janssens
<[EMAIL PROTECTED]> To:
[email protected]
Sent by: cc:
[EMAIL PROTECTED] Subject: [opendx-users] network
buffer size
son.ibm.com
02/04/2003 07:56 AM
Please respond to
opendx-users
I have a very large network (.net file is ~500K) and sometimes have
problems starting up (the UI hangs).
This was discussed some time ago and DX_SOCKET_BUFSIZE was introduced as
a temporary solution. (the problem was caused by data being too big for
the buffer size and this environment variable causes a larger buffer to
be allocated bo Dx's sockets).
However I find that even if I am running with exceedingly large values
for this (150K) sometimes DX still wont start correctly. Is there a
better way to solve this problem?
Regards,
Mattijs
--
/*---------------------------------------------------------*\
| =========== Mattijs Janssens |
| \\ / Development Engineer |
| \\ / |
| \\ / Nabla Ltd. |
| \\ / The Mews, Picketts Lodge |
| \\/ Picketts Lane, Salfords, |
| F ield Surrey RH1 5RG. |
| O peration Tel: +44 (0)1293 821272 |
| A nd Email: [EMAIL PROTECTED] |
| M anipulation URL: http://www.Nabla.co.uk |
\*---------------------------------------------------------*/
