Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Stephane Fillod <f8cfe <at> free.fr>
Subject: Re: R: K3 problem
Newsgroups: gmane.linux.hams.hamlib.devel
Date: Tuesday 8th May 2012 17:42:29 UTC (over 4 years ago)
mar, Maj 08, 2012, Nate Bargmann skribis:
[...]
> No question the serial side is the bottleneck.  As I understand the
> rigctld architecture, the network facing side is threaded but the side
> that communicates with the Hamlib library is not as it is shared amongst
> the threads... 

Right. The rigctl_parse() is protected by a pthread mutex, which makes
multi-access safe event though hamlib is not thread-safe.

Rem: IMO, there's no need of IPC, because the queuing is done by the mutex
when there is contention.

>              ... I have wondered if we could implement a cache to keep
> recently read values around for a while.  That way if rigctld knows that
> a command is in progress, say for changing band, a frequency query would
> return the old value from the cache.  Yes, this would technically be
> false information but the app would probably query again in a short time
> and the command handled and the cache updated with the new value.  I
> think this is important particularly as more programs want to talk to
> the rig at the same time (think CQRlog and Fldigi and possibly other
> combinations).

This is a feature worth to consider. It could easily be done in the
*frontend*, without changing the API or touching the backends. On top
of that, the building blocks exist already.

See the FT747 for example. This rig takes more than 800 ms to send its
status blurb. Hence, two years ago IYRC, we devised a caching system,
for that backend. Here is how it could be reused:

  /* In frontend_get_xxx */
  if (!rig_check_cache_timeout(&rs->status_tv, rs->cache_timeout)) {
    return rs->cached_value;
  } else {
    rs->cached_value = backend_get_xxx();
    /* When updating content, update cache date */
    gettimeofday(&rs->status_tv, NULL);
    return rs->cached_value;
  }

  ...

  /* If you want to force a timeout, e.g. after any rig_set_xxx */
  rig_force_cache_timeout(&rs->status_tv);

status_tv is a struct timeval, and cache functions are already defined in
src/misc.c
The cache_timeout could be changed (or disabled) by rig_set_conf().

Such caching would have to be done independently for every rig_get_xxx()
function, or at least the most regularly requested. The cached values
could be stored in a channel_t variable. I can whip up a patch if you
would like to have a taste of it.
-- 
Stephane - F8CFE

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 
CD: 3ms