trouble with PtMainLoop and threads

I’m working on a Photon application which is multi-threaded, and I’m having
trouble with the event loop. In the first thread, I do the following. Note
that this is NOT the thread which called PtInit().

flags = PtEnter(Pt_EVENT_PROCESS_ALLOW);
PtMainLoop();
PtLeave(flags);

The second thread makes the PtInit() call and sets up the application
widgets. It also tries to stop the event loop once it’s time to quit, by
doing the following.

flags = PtEnter(0);
PtQuitMainLoop();
PtLeave(flags);

What happens is that the second thread completes its call to
PtQuitMainLoop(), but the first thread never exits out of PtMainLoop(). I
don’t want to call PtExit() from the second thread since I need to do some
cleanup.

Is PtQuitMainLoop() guaranteed to force PtMainLoop() to return? Or are
there some caveats? Any suggestions about alternatives would be welcome.
I’m new to Photon programming, and I’m not using Phab.

thanks
Charlie

Charlie Surface <charlie_surface@oti.com> wrote:

What happens is that the second thread completes its call to
PtQuitMainLoop(), but the first thread never exits out of PtMainLoop(). I
don’t want to call PtExit() from the second thread since I need to do some
cleanup.

Is PtQuitMainLoop() guaranteed to force PtMainLoop() to return? Or are
there some caveats? Any suggestions about alternatives would be welcome.
I’m new to Photon programming, and I’m not using Phab.

Like the docs say, PtQuitMainLoop() only affects PtMainLoop() in the
calling thread
. In other words, you need to call PtQuitMainLoop() in
the first thread.

Is it essential to you that the cleanup and the PtExit() must be done in
the first thread? Wouldn’t it be simpler to just do it in the second
thread?

\

Wojtek Lerch QNX Software Systems Ltd.

So PtQuitMainLoop() will only work if used in a callback? I guess this
leads to another question. Is there any way to stop PtMainLoop() from a
different thread, or should I roll my own event loop using PtProcessEvent()
or PhEventRead()?

thanks
Charlie

“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:a8cjq3$lnf$1@nntp.qnx.com

Charlie Surface <> charlie_surface@oti.com> > wrote:

What happens is that the second thread completes its call to
PtQuitMainLoop(), but the first thread never exits out of PtMainLoop().
I
don’t want to call PtExit() from the second thread since I need to do
some
cleanup.

Is PtQuitMainLoop() guaranteed to force PtMainLoop() to return? Or are
there some caveats? Any suggestions about alternatives would be
welcome.
I’m new to Photon programming, and I’m not using Phab.

Like the docs say, PtQuitMainLoop() only affects PtMainLoop() in the
calling thread
. In other words, you need to call PtQuitMainLoop() in
the first thread.

Is it essential to you that the cleanup and the PtExit() must be done in
the first thread? Wouldn’t it be simpler to just do it in the second
thread?

\

Wojtek Lerch QNX Software Systems Ltd.

Charlie Surface <charlie_surface@oti.com> wrote:

So PtQuitMainLoop() will only work if used in a callback?

I believe no, it just has to be called by the thread
which called PtMainLoop. It is the same with mutices,
if one thread locks a mutex, another thread cannot unlock
that mutex.

I guess this
leads to another question. Is there any way to stop PtMainLoop() from a
different thread, or should I roll my own event loop using PtProcessEvent()
or PhEventRead()?

thanks
Charlie

“Wojtek Lerch” <> wojtek_l@yahoo.ca> > wrote in message
news:a8cjq3$lnf$> 1@nntp.qnx.com> …
Charlie Surface <> charlie_surface@oti.com> > wrote:

What happens is that the second thread completes its call to
PtQuitMainLoop(), but the first thread never exits out of PtMainLoop().
I
don’t want to call PtExit() from the second thread since I need to do
some
cleanup.

Is PtQuitMainLoop() guaranteed to force PtMainLoop() to return? Or are
there some caveats? Any suggestions about alternatives would be
welcome.
I’m new to Photon programming, and I’m not using Phab.

Like the docs say, PtQuitMainLoop() only affects PtMainLoop() in the
calling thread
. In other words, you need to call PtQuitMainLoop() in
the first thread.

Is it essential to you that the cleanup and the PtExit() must be done in
the first thread? Wouldn’t it be simpler to just do it in the second
thread?

\

Wojtek Lerch QNX Software Systems Ltd.

Charlie Surface <charlie_surface@oti.com> wrote:

So PtQuitMainLoop() will only work if used in a callback? I guess this

A callback in the wider sense, yes (i.e. a widget callback, an input
proc, a workproc etc.). Well, you could also call it before
PtMainLoop(), but that wouldn’t be very useful.

The main purpose PtQuitMainLoop() was designed for was to let you have a
dynamic pool of threads running the main loop. If you decide that you
have more threads than you want, you’d use PtQuitMainLoop() to make some
of them exit. That’s the only safe way of getting rid of threads that
are running the main loop – cancelling them or calling pthread_exit()
is likely to leave your widgets in a bad state or leak some resources.

Perhaps it’s worth mentioning that PtMainLoop() is not guaranteed to
return immediately after you return from the callback that calls
PtQuitMainLoop(). If you have a different callback that runs its own
modal event loop (for instance, by calling PtNotice() or
PtFileSelection()), and PtQuitMainLoop() is called from within that
loop, the main loop doesn’t get a chance to return until your callback
returns.

leads to another question. Is there any way to stop PtMainLoop() from a
different thread, or should I roll my own event loop using PtProcessEvent()
or PhEventRead()?

You can attach a workproc that calls PtQuitMainLoop(). There’s a
problem with mixing workprocs and threads though – if you have exactly
one thread running the main loop, and it’s waiting for an event while
another thread attaches a workproc, the workproc won’t be called until
you get an event.

You could use a pulse and an input proc to work around this.

\

Wojtek Lerch QNX Software Systems Ltd.

Thanks for the info. I’ll try some other things.

Charlie



“Wojtek Lerch” <wojtek_l@yahoo.ca> wrote in message
news:a8d34a$3vm$1@nntp.qnx.com

Charlie Surface <> charlie_surface@oti.com> > wrote:
So PtQuitMainLoop() will only work if used in a callback? I guess this

A callback in the wider sense, yes (i.e. a widget callback, an input
proc, a workproc etc.). Well, you could also call it before
PtMainLoop(), but that wouldn’t be very useful.

The main purpose PtQuitMainLoop() was designed for was to let you have a
dynamic pool of threads running the main loop. If you decide that you
have more threads than you want, you’d use PtQuitMainLoop() to make some
of them exit. That’s the only safe way of getting rid of threads that
are running the main loop – cancelling them or calling pthread_exit()
is likely to leave your widgets in a bad state or leak some resources.

Perhaps it’s worth mentioning that PtMainLoop() is not guaranteed to
return immediately after you return from the callback that calls
PtQuitMainLoop(). If you have a different callback that runs its own
modal event loop (for instance, by calling PtNotice() or
PtFileSelection()), and PtQuitMainLoop() is called from within that
loop, the main loop doesn’t get a chance to return until your callback
returns.

leads to another question. Is there any way to stop PtMainLoop() from a
different thread, or should I roll my own event loop using
PtProcessEvent()
or PhEventRead()?

You can attach a workproc that calls PtQuitMainLoop(). There’s a
problem with mixing workprocs and threads though – if you have exactly
one thread running the main loop, and it’s waiting for an event while
another thread attaches a workproc, the workproc won’t be called until
you get an event.

You could use a pulse and an input proc to work around this.

\

Wojtek Lerch QNX Software Systems Ltd.