I have a Photon application that uses a PtTimer widget.
I’d like to Trigger or Pulse (whatever) that same timer from my own code.
What software mechanism can I use to wake up that PtTimer?
BTW, this would be across threads within the same application.
Can’t you just set the resources of the timer widget? That’s the approach I
use.
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:ci9fi8$3d1$1@inn.qnx.com…
I have a Photon application that uses a PtTimer widget.
I’d like to Trigger or Pulse (whatever) that same timer from my own code.
What software mechanism can I use to wake up that PtTimer?BTW, this would be across threads within the same application.
Bill Caroselli wrote:
I have a Photon application that uses a PtTimer widget.
I’d like to Trigger or Pulse (whatever) that same timer from my own code.
What software mechanism can I use to wake up that PtTimer?
Timer widgets don’t really sleep… Do you just want to invoke the
widget’s callback, or do you also want to stop or restart the timer? To
invoke the callback, well, you could just call your callback function.
To stop or restart the timer, use the widget’s resources. Or is what
you’re trying to do too tricky for this simple advice to work?
A bit of background: PtTimer uses timer events. When the widget is
being realized, or when you set the timeout in a realized widget, it
calls PtTimerArm() to ask Photon for a timer event after the specified
amount of time. When the event comes back, the widget invokes your
callback and, depending on whether the repeat interval is set, calls
PtTimerArm() again.
BTW, this would be across threads within the same application.
Does it matter which thread you’d be invoking the callbacks from?
The program has two threads. The main thread is the user interface
thread. The second thread is a communications thread.
The timer is set to a relativly slow count, 30 seconds. But when I
receive a specific message I want the second thread to force the first
thread (the UI thread) to call the callback.
I really don’t want to just call that callback function from the second
thread. That would break many assumptions about what data can be
accessed from what thread. I.E. data that is not protected with
syncronisation locks.
Wojtek Lerch <Wojtek_L@yahoo.ca> wrote:
WL > Bill Caroselli wrote:
I have a Photon application that uses a PtTimer widget.
I’d like to Trigger or Pulse (whatever) that same timer from my own code.
What software mechanism can I use to wake up that PtTimer?
WL > Timer widgets don’t really sleep… Do you just want to invoke the
WL > widget’s callback, or do you also want to stop or restart the timer? To
WL > invoke the callback, well, you could just call your callback function.
WL > To stop or restart the timer, use the widget’s resources. Or is what
WL > you’re trying to do too tricky for this simple advice to work?
WL > A bit of background: PtTimer uses timer events. When the widget is
WL > being realized, or when you set the timeout in a realized widget, it
WL > calls PtTimerArm() to ask Photon for a timer event after the specified
WL > amount of time. When the event comes back, the widget invokes your
WL > callback and, depending on whether the repeat interval is set, calls
WL > PtTimerArm() again.
BTW, this would be across threads within the same application.
WL > Does it matter which thread you’d be invoking the callbacks from?
I was just looking through the Programmer’s Guide. I was considering
using PtSendEventToWidget() but it says that that is not thread safe.
So how can a second thread force the first thread to execute a callback?
Bill Caroselli <qtps@earthlink.net> wrote:
BC > The program has two threads. The main thread is the user interface
BC > thread. The second thread is a communications thread.
BC > The timer is set to a relativly slow count, 30 seconds. But when I
BC > receive a specific message I want the second thread to force the first
BC > thread (the UI thread) to call the callback.
BC > I really don’t want to just call that callback function from the second
BC > thread. That would break many assumptions about what data can be
BC > accessed from what thread. I.E. data that is not protected with
BC > syncronisation locks.
Bill Caroselli wrote:
I was just looking through the Programmer’s Guide. I was considering
using PtSendEventToWidget() but it says that that is not thread safe.So how can a second thread force the first thread to execute a callback?
Couldn’t you just use PtAppCreatePulse/PtPulseArm and MsgDeliverEvent from your other thread ?
Rennie
Rennie Allen <rallen@csical.com> wrote:
RA > Bill Caroselli wrote:
I was just looking through the Programmer’s Guide. I was considering
using PtSendEventToWidget() but it says that that is not thread safe.So how can a second thread force the first thread to execute a callback?
RA > Couldn’t you just use PtAppCreatePulse/PtPulseArm and MsgDeliverEvent from your other thread ?
RA > Rennie
It says that PtAppCreatePulse() is not thread safe.
So I assume I can not call this function from a non-photon thread.
Bill Caroselli wrote:
Rennie Allen <> rallen@csical.com> > wrote:
RA > Bill Caroselli wrote:I was just looking through the Programmer’s Guide. I was considering
using PtSendEventToWidget() but it says that that is not thread safe.So how can a second thread force the first thread to execute a callback?
RA > Couldn’t you just use PtAppCreatePulse/PtPulseArm and MsgDeliverEvent from your other thread ?RA > Rennie
It says that PtAppCreatePulse() is not thread safe.
So I assume I can not call this function from a non-photon thread.
You wouldn’t call PtAppCreatePulse() from your “other” thread.
You would create the pulse in your photon thread, and then send a
message to your “other” thread containing the pulse. You would
then use the rcvid/pulse pair as args to MsgDeliverEvent,
whenever you wanted to cause the photon thread to run the
“timer callback”.
Rennie
I think he meant PtAppCreatePulse() and PtPulseArm() (and
PtAppAddInput()) from the Photon thread, and then just MsgDeliverEvent()
from the other thread. That’s a reasonable solution if you want the
second thread to reliably run at a priority above the Photon stuff.
Since MsgDeliverEvent takes a connection id, you will also need to
connect to the channel used by the Photon library. PtChannelCreate()
will tell you the channel ID. You can do all this at initialization, in
the Photon thread.
Bill Caroselli wrote:
Rennie Allen <> rallen@csical.com> > wrote:
RA > Bill Caroselli wrote:I was just looking through the Programmer’s Guide. I was considering
using PtSendEventToWidget() but it says that that is not thread safe.
You could work around the thread-unsafety of this function, or almost
any other Photon function, by calling PtEnter(); but since PtEnter() is
based on a condvar, it doesn’t propagate your priority. And if you’re
using your own mutextes for synchronization, you would need to carefully
order things to make sure that your mutextes and PtEnter() don’t deadlock.
Besides, PtSendEventToWidget() doesn’t send any event. It just runs
library code that invokes callbacks. It would run the callbacks in your
second thread.
So how can a second thread force the first thread to execute a callback?
RA > Couldn’t you just use PtAppCreatePulse/PtPulseArm and MsgDeliverEvent from your other thread ?RA > Rennie
It says that PtAppCreatePulse() is not thread safe.
So I assume I can not call this function from a non-photon thread.
Wojtek Lerch wrote:
And if you’re
using your own mutextes for synchronization, you would need to carefully
order things to make sure that your mutextes and PtEnter() don’t deadlock.
I do know the word is “mutexes”, not “mutextes”. But apparently, my
fingers disagree. :-/
Thank you.
This gives me much to try.
Wojtek Lerch <Wojtek_L@yahoo.ca> wrote:
WL > I think he meant PtAppCreatePulse() and PtPulseArm() (and
WL > PtAppAddInput()) from the Photon thread, and then just MsgDeliverEvent()
WL > from the other thread. That’s a reasonable solution if you want the
WL > second thread to reliably run at a priority above the Photon stuff.
WL > Since MsgDeliverEvent takes a connection id, you will also need to
WL > connect to the channel used by the Photon library. PtChannelCreate()
WL > will tell you the channel ID. You can do all this at initialization, in
WL > the Photon thread.
WL > Bill Caroselli wrote:
Rennie Allen <> rallen@csical.com> > wrote:
RA > Bill Caroselli wrote:I was just looking through the Programmer’s Guide. I was considering
using PtSendEventToWidget() but it says that that is not thread safe.
WL > You could work around the thread-unsafety of this function, or almost
WL > any other Photon function, by calling PtEnter(); but since PtEnter() is
WL > based on a condvar, it doesn’t propagate your priority. And if you’re
WL > using your own mutextes for synchronization, you would need to carefully
WL > order things to make sure that your mutextes and PtEnter() don’t deadlock.
WL > Besides, PtSendEventToWidget() doesn’t send any event. It just runs
WL > library code that invokes callbacks. It would run the callbacks in your
WL > second thread.
So how can a second thread force the first thread to execute a callback?
RA > Couldn’t you just use PtAppCreatePulse/PtPulseArm and MsgDeliverEvent from your other thread ?RA > Rennie
It says that PtAppCreatePulse() is not thread safe.
So I assume I can not call this function from a non-photon thread.
Bill Caroselli wrote:
Thank you.
This gives me much to try.
Just to be clear, MsgDeliverEvent takes a rcvid, not a connection id.
Rennie
Rennie Allen wrote:
Just to be clear, MsgDeliverEvent takes a rcvid, not a connection id.
Um, right. I was thinking about MsgSendPulse().