David, I think I chased this one down. Here's a note from the archives... give it a try.
Greg I've recently run down a problem that can cause a hang when you try to execute extremely large networks that involves a deadlock situation in the socket communication between the exec and the UI. To get around it I've added an environment variable that allow you to specify a larger socket buffer size (if the setsockopt call is available), named DX_SOCKET_BUFSIZE. The value assigned to it is passed as the parameter to setsockopt for SOL_SNDBUF and SOL_RCVBUF. I think the default is 32767, and the range is clamped to the max allowed by the system. The value used is clamped to the max allowed by the system; see your sysadmin if you need up this. I'm using 262144. Greg David Thompson <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 03/01/2002 03:57:26 PM Please respond to [email protected] Sent by: [EMAIL PROTECTED] To: [email protected] cc: Subject: [opendx-dev] Packet problem I've noticed going through the samples, one right after another quite quickly--that once in a while, I get into a race condition in communication between dxui and the exec. I just attached to one of this hung execs and interrupted, and it said it was stuck at sfile.c:191, which is a write. I will try and track this down further, but has anybody else seen this behavior? This is going to be one of those tough ones to nail. David -- ............................................................................. David L. Thompson Visualization and Imagery Solutions, Inc. mailto:[EMAIL PROTECTED] 5515 Skyway Drive, Missoula, MT 59804 Phone : (406)257-8530
