Hi Corey,
Thanks for the information.
For this problem of reading sensor's reading, we are thinking to use
semaphores, on which our function which gets the sensor's reading, will be
waiting for. And the call back function which actually gets called when the
sensor reading is available/read, will signal the semaphore before leaving. Now
once the data is available, our function which was waiting on the semaphore
will have the sensor reading (obtained from call back data passed to call back
function), and resume and continue.
Also one more thing i have observed, (may be helpful to others) that suppose we
are running the "operation loop" as separate thread, then the call back
functions are getting run as part of (in context of ) that thread.
So using semaphores for synchronizing call back function with the main code
flow is possible (as both runs on separate threads).
Thanks and regards
S Sarath
On Thursday, May 1, 2014 4:53 AM, Corey Minyard <[email protected]> wrote:
On 04/30/2014 12:15 PM, sarath azad wrote:
> Hi Corey,
>
> Suppose we have a sensor's ID, then is there a way such that we can
> call a function which will return its reading?
> Currently what I could see is that we can only
> call ipmi_sensor_pointer_cb() to call a callback function with
> pointer to the sensor
> inside this call back call ipmi_sensor_get_reading() passing
> another call back function
> now in this final call back function the sensor reading is
> available and we fill it in call back data (void *cb_data)
> So now through void *cb_data we can get the sensor reading. But the
> initial call to get the sensor reading, is not waiting for sensor
> reading value and simply continues after
> calling ipmi_sensor_pointer_cb().
What you state is correct.
>
> Could you please tell if there is any other way to get the sensor
> readings like calling a function which could fetch or wait till sensor
> reading is available and return the value ?
>
> What is the general way to get the sensor readings using OpenIPMI library?
OpenIPMI is completely non-blocking. This means that every single
function will run without doing anything that will block waiting for
something. Thus the callbacks for when things complete. You could
build a blocking framework on top of OpenIPMI, but nobody has done it at
this point.
I know it's inconvenient for what you want, but OpenIPMI was designed to
scale to monitor thousands of IPMI systems continuously. You just can't
do that with blocking calls. And the event-driven structure works very
nicely with GUIs.
-corey
>
> thanks and regards
> S Sarath
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
