Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/Non blocking open?/List of Posts
BroadcastCommunity.qnx.com will be offline from May 31 6:00pm until June 2 12:00AM for upcoming system upgrades. For more information please go to https://community.qnx.com/sf/discussion/do/listPosts/projects.bazaar/discussion.bazaar.topc28418
Forum Topic - Non blocking open?: (6 Items)
   
Update
Elena Laskavaia
07/24/2008 11:17 AM
post10934
Non blocking open?   
I have a resource manager for lets say /dev/xxx
My client opens file /dev/xxx for writing
open("/dev/xxx", O_WRONLY | O_NONBLOCK | O_CLOEXEC | O_NOCTTY)

The problem is when resource manager is stopped (SIGSTOP) this call is hanging indefinitely.
If there any way to "open" it so if it cannot access resource manager it returns and sets errno to something like EAGAIN
?
David Sarrazin
07/24/2008 11:26 AM
post10935
RE: Non blocking open?   
Is the resouce manager already STOPPED when the open() function is run?
In that case your application is REPLY blocked on the pathmgr, who is
SEND blocked on your resmgr.  If the resmgr gets the SIGSTOP after
open() and pathmgr have resolved which resmgr you should be talking to,
then your open() is SEND (or REPLY) blocked on your resmgr.

Why is the resmgr getting a SIGSTOP?  That tends to be a good way to
lock everything up. 

> -----Original Message-----
> From: Elena Laskavaia [mailto:elaskavaia@qnx.com] 
> Sent: July 24, 2008 11:17 AM
> To: ostech-core_os
> Subject: Non blocking open?
> 
> I have a resource manager for lets say /dev/xxx My client 
> opens file /dev/xxx for writing open("/dev/xxx", O_WRONLY | 
> O_NONBLOCK | O_CLOEXEC | O_NOCTTY)
> 
> The problem is when resource manager is stopped (SIGSTOP) 
> this call is hanging indefinitely.
> If there any way to "open" it so if it cannot access resource 
> manager it returns and sets errno to something like EAGAIN?
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post10934
> 
>
Mario Charest
07/24/2008 11:30 AM
post10936
Re: Non blocking open?   
> I have a resource manager for lets say /dev/xxx
> My client opens file /dev/xxx for writing
> open("/dev/xxx", O_WRONLY | O_NONBLOCK | O_CLOEXEC | O_NOCTTY)
> 
> The problem is when resource manager is stopped (SIGSTOP) this call is hanging
>  indefinitely.
> If there any way to "open" it so if it cannot access resource manager it 
> returns and sets errno to something like EAGAIN?


You could try setting up a alarm with a signal or TimerTimeout()
Colin Burgess(deleted)
07/24/2008 11:35 AM
post10938
Re: Non blocking open?   
O_NONBLOCK doesn't impose a limit on the processing of the open request - it imposes a limit on how long the open can 
block
AFTER the open has actually been processed.

If the kernel or resource manager cannot process the open request, then O_NONBLOCK cannot help you.

Really what you need in this case is a timeout on the send/reply states I guess, however that would involve a custom
_connnect_* sequence which is not going to be trivial.

Setting up a signal will unblock you if you are SEND blocked on the server, but if you are REPLY blocked it will
simply send an unblock pulse to the server, and you will continue to be blocked.

Colin

Elena Laskavaia wrote:
> I have a resource manager for lets say /dev/xxx
> My client opens file /dev/xxx for writing
> open("/dev/xxx", O_WRONLY | O_NONBLOCK | O_CLOEXEC | O_NOCTTY)
> 
> The problem is when resource manager is stopped (SIGSTOP) this call is hanging indefinitely.
> If there any way to "open" it so if it cannot access resource manager it returns and sets errno to something like 
EAGAIN?
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post10934
> 

-- 
cburgess@qnx.com
Elena Laskavaia
07/24/2008 11:45 AM
post10939
Re: Non blocking open?   
Thanks, this is useful. I guess it is the same for read and write. Chances of process being hit by SIGSTOP during 
processing of open is slim by possible. The other option I guess to re-implement client to use "thread-per-file" 
approach - in this case if it blocked on one file at least it can be used with other files (which is the actual problem 
now - deadlock while debugging the program using qconn which blocks on resource manager which is being debugged).
Thomas Fletcher
07/28/2008 9:04 AM
post11137
Re: Non blocking open?   
Colin Burgess wrote:
> O_NONBLOCK doesn't impose a limit on the processing of the open request - it imposes a limit on how long the open can 
block
> AFTER the open has actually been processed.
>
> If the kernel or resource manager cannot process the open request, then O_NONBLOCK cannot help you.
>
> Really what you need in this case is a timeout on the send/reply states I guess, however that would involve a custom
> _connnect_* sequence which is not going to be trivial.
>
> Setting up a signal will unblock you if you are SEND blocked on the server, but if you are REPLY blocked it will
> simply send an unblock pulse to the server, and you will continue to be blocked.
>   
True .. but in the case Elena is describing, that would be ok.  Since 
the open is where the blocking is occuring ... and we are presuming here
that it is in fact SEND blocked and not blocked internally somewhere 
after being received ... then having the kernel kick the client back with
an error would be ok.  If the server has already processed the request 
(ie we are no longer talking about open, but read/write etc) then the
server should have an unblock handler and handle signalling requests 
(not to mention O_NONBLOCK) properly.

Thomas
> Colin
>
> Elena Laskavaia wrote:
>   
>> I have a resource manager for lets say /dev/xxx
>> My client opens file /dev/xxx for writing
>> open("/dev/xxx", O_WRONLY | O_NONBLOCK | O_CLOEXEC | O_NOCTTY)
>>
>> The problem is when resource manager is stopped (SIGSTOP) this call is hanging indefinitely.
>> If there any way to "open" it so if it cannot access resource manager it returns and sets errno to something like 
EAGAIN?
>>
>>
>> _______________________________________________
>> OSTech
>> http://community.qnx.com/sf/go/post10934
>>
>>     
>
>

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems