EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: R3.14.8 Status/logClient patch
From: "Jeff Hill" <[email protected]>
To: "'Benjamin Franksen'" <[email protected]>, <[email protected]>
Date: Wed, 16 Nov 2005 17:52:05 -0700
Ben,

My standard approach is to have two threads per circuit. This greatly
simplifies the code and the overhead for the threads does not, IMHO, appear
to be that bad compared to what is needed for the socket, the buffering,
etc. Use of non-blocking IO can easily double the size of the code - BTDT.

In this logClient case only one thread is needed. I doubt that there would
be more than a handful of logging threads per IOC so it certainly seems like
a reasonable approach.

PS: It might be a good idea also to call shutdown for the read side of the
log client's socket in order to conserve resources. It looks like the log
server is doing this for its write side, but the log client could probably
also benefit by shutting down its read side.

Jeff

> -----Original Message-----
> From: Benjamin Franksen [mailto:[email protected]] 
> Sent: Wednesday, November 16, 2005 5:07 PM
> To: [email protected]
> Subject: Re: R3.14.8 Status/logClient patch
> 
> 
> On Wednesday 16 November 2005 21:56, Jeff Hill wrote:
> > I did think of one issue. This is using non blocking IO after the 
> > connect completes. It appears that a delta is that the logRestart 
> > thread is now doing the periodic flush for *multiple* logging 
> > circuits. Therefore, if one of the log circuits isnt flowing for 
> > whatever reason (disk full, marginal circuit, server system 
> power off, 
> > etc), then all of the other log circuits will not be flushed untill 
> > logClientSend is called and the specified message will not fit (the 
> > buffers capacity is exceeded). Since the internal IP kernel 
> timeouts 
> > for circuit disconnect can be quite long this might prove to be 
> > problematic.
> 
> Hi Jeff,
> 
> the simplest way out is to use multiple restart/flush 
> threads, one for 
> each log client. It appears that this has the side-advantage of 
> somewhat simplifying the code since global variables are no longer 
> needed.
> 
> Caveat: I don't know what applications (beside the standard 
> ioc log) use 
> the logClient facility. If there exist applications that create a lot 
> of such clients this would unduly increase IOC load. I don't believe 
> that this is the case, though, it doesn't make much sense. At the 
> moment I am aware of only one custom application that will use the 
> feature at all, namely caPutLog, although others are conceivable.
> 
> Ben
> 
> PS: One could also use non-blocking send and multiplex clients with a 
> select call. This would probably be more complex and also 
> harder to do 
> in a portable manner, thorough testing on different platforms etc. No 
> way to get this into R3.14.8.
> 



Replies:
Re: R3.14.8 Status/logClient patch Marty Kraimer
References:
Re: R3.14.8 Status/logClient patch Benjamin Franksen

Navigate by Date:
Prev: Re: R3.14.8 Status/logClient patch Benjamin Franksen
Next: Re: Build system problem Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: R3.14.8 Status/logClient patch Benjamin Franksen
Next: Re: R3.14.8 Status/logClient patch Marty Kraimer
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·