|
It is currently Tue Feb 07, 2012 9:33 pm
|
View unanswered posts | View active topics
| Welcome |
|
Welcome to RHAPSODY4YOU
You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, respond to polls, upload and download content, and access many other special features. Registration is fast, simple, and absolutely free, so please, register to join our community today. |
 |
|
 |
|
| Author |
Message |
|
Christian
|
Post subject: oxf and unix signals Posted: Tue Jul 14, 2009 9:35 am |
Joined: Tue Jul 14, 2009 9:21 am Posts: 22 Location: Germany
|
|
Hi,
I'm having problems catching unix signals when running with the oxf.
I have an externally developed (posix) thread that simply waits for signals to occur. It is tested and works just fine when running without oxf. But when running with oxf the thread does not catch any signals anymore.
I couldn't find anything related to that topic in the Rhapsody documentation. Does anyone know what's going on here?
Thanks,
Christian
|
|
|
|
 |
|
shanz
|
Post subject: OMThread Posted: Tue Jul 14, 2009 12:59 pm |
Joined: Wed May 07, 2008 3:50 pm Posts: 148 Location: Horsham, W Sussex, England
|
|
In Rhapsody, an 'active' class becomes a thread which derives from OMThread. The OS adapter (eg: linuxOS.cpp) will show the implementation of this class for your environment (eg: linux).
Not sure if this helps you or not! I suspect you'll be asked to explain in more detail.
|
|
|
|
 |
|
Christian
|
Post subject: solved Posted: Wed Jul 15, 2009 1:24 pm |
Joined: Tue Jul 14, 2009 9:21 am Posts: 22 Location: Germany
|
|
Hi Shanz,
thanks for your reply.
It seems I tracked down the problem -- wich actually had nothing to do with the oxf: The signal-catching thread I was talking about required that all signals be blocked for all threads in the program. The signal-catching thread itself would sigwait() for incoming signals and then take proper action. In my non-working example there was a thread implicitly created and started before the signal-catching thread. For this very thread not all signals were blocked. In this case an incoming signal was delivered to the first thread where the default handler for the given signal was executed -- so the behaviour I expected did not occur.
So the solution was simply to block all signals before the first thread is created.
Christian
|
|
|
|
 |
|
|
 |
|
 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|