From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4DEA7592.6030802@tecmav.com>
Date: Sat,  4 Jun 2011 20:12:34 +0200
From: adriano <a.verardo@tecmav.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <f6bb6caf8b5d268f957a75db4b958a38@terzarima.net>
In-Reply-To: <f6bb6caf8b5d268f957a75db4b958a38@terzarima.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] a pair nec bugs
Topicbox-Message-UUID: eaf86294-ead6-11e9-9d60-3106f5b1d025

Charles Forsyth wrote:
> what about applications that need to get the nsec frequently?
> *in those applications*, i write
>
>
Hi, all

Last month I had problems in a appl made up by 12 threads using a shared
file table.
Six of them continuosly get the time every 20..100 ms.
The last version of the appl worked perfectly since 2009, until I
changed a few details.
 From that point on I frequently had a messy file table and sometimes a
crash,
with a overall behaviour depending on the hw, on the presence of debug
print(), on
the network load etc etc ...

With /dev/bintime unexpectedly closed and viewing the nsec() code, I
thought to a critical race too.

Two weeks ago I've slightly modified the application, to have separate
(RFFDG) fd tables per thread.
This way, in my specific appl,  the problem seems to be avoided. All the
(15) machines work ok now.

adriano