Patrick Mueller <Patrick_Mueller@oti.com> wrote:
Patrick Mueller <> Patrick_Mueller@oti.com> > wrote:
We have a multi-threaded app that uses PtRaw widgets. I’m getting a
strange
application error and in tracking it down I’ve noticed that I have one
thread which has performed a PtEnter(0) and then called PtClippedBlit.
The
thread is frozen in that call. At the same time, a draw function has
been
By “frozen” do you mean blocked? What is it blocked on according to
pidin?
Yes, blocked. We are inside of PtClippedBlit, and the thread is blocked.
Actually, I don’t have a good way of associating my applications threads
with the OS ones. I will see if there’s some way for me to do this. Given
my email address, you probably know what I’m working on > 
> . So I don’t
know specifically what it is blocked on.
It might help to know which blocked state the thread is in. For
instance, if it’s blocked inside PtEnter(), it should be
CONDVAR-blocked.
But this seems odd. 0 doesn’t seem to be a valid value for PtEnter(); I
Zero is a perfectly valid value for PtEnter().
The docs indicate the parm can be one of:
Pt_EVENT_PROCESS_ALLOW == 1
Pt_EVENT_PROCESS_PREVENT == 2
What does 0 mean? The doc for PtEnter() should be updated to indicate this.
I actually changed all of our usages to 2 and nothing changed.
My copy of the docs says:
The value of flags can be one of:
…
In most cases, it’s better to pass zero for flags, in which case the
thread’s status as event reader or nonreader doesn’t change.
Perhaps it would be clearer if the first sentence was
The value of flags can be zero or one of
…
Are you sure those are two different threads that you’re talking
about? >
Yes, the PtClippedBlit() has blocked one thread, and the other thread is in
the draw function. The draw function is running on the ‘main’ thread (the
one processing the Photon event queue), the PtClippedBlit running on a
different thread.
I assume if my draw function was invoked, but then a thread switch occurred
and I tried to do a PtEnter(0) on this different thread, the PtEnter(0) call
would block until the draw function was complete? Or do I need to put an
Yes. A draw function runs with
explicit PtEnter(0) in my draw function? Or must I never put a PtEnter(0)
Calling PtEnter() from a draw function is pointless but harmless: since
a draw function is invoked by a thread that already has the lock,
PtEnter() will fail.
OTOH, calling PtLeave() from a draw function guarantees trouble.
in my draw function? Or any callback for that matter (plain-old widget
callback, input callback, draw function, workproc???)
Whenever the Photon library calls your code, the calling thread already
owns the lock, and a call to PtEnter() will fail. Depending on the
callback, it may be safe to call PtLeave() from your code, provided you
call PtEnter() before returning. This can be done in most of the
callback types you listed, but not in a PtRaw draw function. A draw
function (as well as several other widget class methods that PtRaw turns
into user-level callbacks) is not allowed to do pretty much anything
that may end up modifying the state of any widgets – and a call to
PtLeave() does let other threads modify widgets.
I’m guessing that we may have screwed the system somehow shortly before this
happened, and we are seeing symptoms of
hosing the innards of the Photon runtime …
That’s a possibility…
And again, what I’m actually seeing is not a Photon problem, but a strange
application error that I can’t really account for. Wild pointer accesses
perhaps. In debugging the state of the problem, I noticed this odd set of
Photon thread interactions and it just didn’t seem right …
Another easy way to screw things up is by having a callback that calls
PtEnter(), ignores its failure, and then calls PtLeave() and returns.
–
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.