Michael,
You are welcome. As I said, it was a quick draft solution and I didn't
test enough to see how well/bad it performs. Furthermore, I hardly used
those timer functions before, I could be doing something wrong there as
well. Did you check that I'm using those correctly?
What happens when the program stop prematurely? Does it crash or just
silently stops?
I will do more testing on my end when I get a chance and let you know.
One more thing, you are using a year old version of Unicon, while I don't
expect this to affect this program but it worth trying.
Cheers,
Jafar
On Sun, Nov 13, 2016 at 11:28 PM, Michael Meehan <michael.mee...@wwu.edu>
wrote:
> Jafar,
>
> First, thanks so much for taking the time to put together your sketch for a
> solution to the problem of creating a timer using loadfunc and a call to
> setitimer. It really helped refresh my memory about how things were done
> with
> loadfunc without having to resort to reading the tech report.
>
> Unfortunately, I think I have uncovered a bug or at least a limitation in
> the
> implementation. When I run the solution you posted it will work for a few
> cycles
> printing "fire timer" but eventually will abort. The number of cycles
> before
> it breaks is indeterminate, sometimes as few as 3 sometimes as many as 40
> or so.
> The version and features I am running reports
>
> Running Unicon Version 13.0 alpha. Oct 1, 2015
> UNIX
> POSIX
> DBM
> ASCII
> co-expressions
> dynamic loading
> environment variables
> event monitoring
> external functions
> keyboard functions
> large integers
> multiple programs
> pattern type
> pipes
> pseudo terminals
> system function
> messaging
> libz file compression
> PNG images
> SQL via ODBC
> CCompiler gcc 5.4.0
> Physical memory: 4142153728 bytes
> Revision
> Arch x86_64
> CPU cores 2
>
> I tried various rearrangements of things to try to determine where the
> problem
> might be and to try to find a possible work-around. Some of them seem to
> consistently run for more cycles of the timer before dying but will
> eventually
> die. I can post all my various approaches and test run results if it would
> be
> of interest.
>
> If you do not see this behavior on your system, please let me know so I can
> try to determine what is possibly not installed properly on my setup.
>
>
> Michael Meehan
> mee...@wwu.edu for work-related items only
> jmichaelmee...@gmail.com for non-work-related items only
>
> ________________________________________
> From: Jafar Al-Gharaibeh <to.ja...@gmail.com>
> Sent: Thursday, November 10, 2016 10:14:10 PM
> To: Jeffery, Clint (jeffe...@uidaho.edu)
> Cc: Michael Meehan; Unicon group
> Subject: Re: [Unicon-group] SIGALRM
>
> Michael,
>
> I had 15 minutes this evening to quickly hack a draft solution for you.
> I posted it on Unicon's discussion page:
>
> https://sourceforge.net/p/unicon/discussion/contributions/thread/db34541b/
>
> Regards,
> Jafar
>
> On Thu, Nov 10, 2016 at 7:43 PM, Jeffery, Clint (jeffe...@uidaho.edu
> <mailto:jeffe...@uidaho.edu>) <jeffe...@uidaho.edu<mailto:je
> ffe...@uidaho.edu>> wrote:
>
> Hi Michael,
>
>
> Always nice to hear from a fellow Washingtonian.
>
>
> I am aware of various alarming things being done in Unicon before, but
> have not seen code of the sort you describe. It should be a great test of
> trap() and the posix facilities. In grepping for possible interactions, I
> noticed that the URL-reading code in the messaging facilities sets a
> SIGALRM handler to do a timeout when it attempts to connect to a web
> server, but as long as you are not simultaneously trying to open() things
> with mode "m" you should be OK.
>
>
> Cheers,
>
> Clint
>
>
> ------------------------------------------------------------
> -----------------------------------------
>
> MM> I'm writing a unicon program that needs to set a timer. Has anyone
> every written a c loadfunc for setitimer and/or getitime so that the unicon
> program can trap SIGALRM and know when the interval has expired. Thought I
> would check to see if anyone had already done it before trying to build it.
>
> #include <sys/time.h>
>
> int getitimer(int which, struct itimerval *curr_value);
> int setitimer(int which, const struct itimerval *new_value,
> struct itimerval *old_value);
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> _______________________________________________
> Unicon-group mailing list
> Unicon-group@lists.sourceforge.net<mailto:Unicon-
> gr...@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
>
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
