It is currently Tue Feb 07, 2012 9:13 pm

All times are UTC



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.





 Page 1 of 1 [ 3 posts ] 
Author Message
 Post subject: oxf and unix signals
PostPosted: 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


Offline
 Profile  
 
 Post subject: OMThread
PostPosted: 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.


Offline
 Profile  
 
 Post subject: solved
PostPosted: 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


Offline
 Profile  
 
Display posts from previous:  Sort by  
 Page 1 of 1 [ 3 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 0 guests


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

Search for:


suspicion-preferred