TeamForge : Post

Forum Topic - posix_spawn() blocks indefinetely: (5 Items)

View: as

Eric Shufro(deleted)

02/21/2013 4:44 PM

post99439

Hello.  Does anyone have any idea why posix_spawn() blocks my process indefinitely within MsgSendvnc()?

The preconditions are as follows :

(1) Process of priority 10 is deliberately placed in to an infinite loop without blocking; e.g. while (1) {};
(2) Process of priority 20 attempts to spawn a new process of priority 8 using posix_spawn() and becomes blocked.

It appears that posix_spawn() is waiting for the pid() of the new process to become available, and in doing so, perhaps 
requires that the process be scheduled.  This seems counter intuitive since the pid should be available at the time that
 the process is loaded into the process space and marked ready.

Nonetheless, since lower priority process is readied and is unable to run due to the slightly higher priority process 
spinning, my highest priority process is unable to continue and remains blocked in what appears to be priority inversion
.

OS Version : Neutrino 6.5.0

Thoughts?

Thank you in advance.

--Eric

Neil Schellenberger(deleted)

02/21/2013 5:02 PM

post99442

RE: posix_spawn() blocks indefinetely

In this case, the system is working as intended.  The higher priority thread has deliberately chosen to wait on a lower 
priority action: the loading of the lower priority process image file.  

Remember that POSIX requires that if posix_spawn() cannot " ... create a new process (child process) from the specified 
process image" that "... no child process shall be created, the value stored into the variable pointed to by a non-NULL 
pid is unspecified, and an error number shall be returned as the function return value to indicate the error."  
Fulfilling this condition requires more than just the creation of the process container (i.e. a pid) -- it must actually
 load the image.

________________________________________
From: Eric Shufro [community-noreply@qnx.com]
Sent: February-21-13 4:44 PM
To: ostech-core_os
Subject: posix_spawn() blocks indefinetely

Hello.  Does anyone have any idea why posix_spawn() blocks my process indefinitely within MsgSendvnc()?

The preconditions are as follows :

(1) Process of priority 10 is deliberately placed in to an infinite loop without blocking; e.g. while (1) {};
(2) Process of priority 20 attempts to spawn a new process of priority 8 using posix_spawn() and becomes blocked.

It appears that posix_spawn() is waiting for the pid() of the new process to become available, and in doing so, perhaps 
requires that the process be scheduled.  This seems counter intuitive since the pid should be available at the time that
 the process is loaded into the process space and marked ready.

Nonetheless, since lower priority process is readied and is unable to run due to the slightly higher priority process 
spinning, my highest priority process is unable to continue and remains blocked in what appears to be priority inversion
.

OS Version : Neutrino 6.5.0

Thoughts?

Thank you in advance.

--Eric




_______________________________________________

OSTech
http://community.qnx.com/sf/go/post99439
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com

Eric Shufro(deleted)

02/22/2013 9:16 AM

post99458

Re: RE: posix_spawn() blocks indefinetely

Neil,

Thank you for the reply.  I find it interesting that the loading of the process image would occur at a lower priority 
since it seems as though this activity would occur from within the context of the caller.  Of course, creating the 
'container' and loading the process are still different than making the process/main thread ready and actually selecting
 it to run.  My anticipation was that the process would be loaded, marked ready and simply not scheduled since its 
priority is less than a higher priority thread that is also ready.  That's why I had expected the call to return with 
the PID without blocking.

Do most modern operating systems *wait* for the process to load at the configured or inherited priority or is this 
specific to the QNX Neutrino implementation?

Thanks,

--Eric

Neil Schellenberger(deleted)

02/22/2013 5:28 PM

post99484

RE: RE: posix_spawn() blocks indefinetely

The process container is created at the specified priority and, as you might expect, the loader code runs within that 
process container (with those privileges etc.)

I'd have to check to see what other operating systems do, but that's what Neutrino does ;-)

One standard trick that we use to arrange for a spawned process to be modified before it starts running, is to start it 
held.  In your example, you'd spawn the process at your prio but held; then you'd lower its prio and release it.

________________________________________
From: Eric Shufro [community-noreply@qnx.com]
Sent: February-22-13 9:16 AM
To: ostech-core_os
Subject: Re: RE: posix_spawn() blocks indefinetely

Neil,

Thank you for the reply.  I find it interesting that the loading of the process image would occur at a lower priority 
since it seems as though this activity would occur from within the context of the caller.  Of course, creating the 
'container' and loading the process are still different than making the process/main thread ready and actually selecting
 it to run.  My anticipation was that the process would be loaded, marked ready and simply not scheduled since its 
priority is less than a higher priority thread that is also ready.  That's why I had expected the call to return with 
the PID without blocking.

Do most modern operating systems *wait* for the process to load at the configured or inherited priority or is this 
specific to the QNX Neutrino implementation?

Thanks,

--Eric





_______________________________________________

OSTech
http://community.qnx.com/sf/go/post99458
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com

Eric Shufro(deleted)

02/23/2013 3:45 PM

post99491

Re: RE: RE: posix_spawn() blocks indefinetely

Excellent idea. 

Thank you for your suggestions.

--Eric

Return