Menu
▾
▴
#54 vxworks pthread task IDs
Using ION 3.1.3:
When running on vxworks, bping is not able to receive the responses to its pings. This may be symptomatic of a larger problem with the sm_TaskId functions and how vxworks treats pthreads however.
When using bping on vxworks 6.3, the filter in libbp.c around line 550 ("Can't receive: not owner of endpoint.") is triggered, because the way that the sm_TaskId functions seem to operate on vxworks pthreads.
bping spawns two threads, one for sending bundles, and one for receiving. The receiving and sending threads wind up with different sm_TaskIdSelf() results, and the receiving thread specifically has a different TaskId than the thread that bound and owns the endpoint, which is what prevents that check in libbp.c line 550 from succeeding.
The temporary solution I'm using (rather than tinkering with the sm_* functions) is to only return failure in that libbp.c check #ifndef VXWORKS, but this is kind of a hack. The only downside I see is that potentially tasks can steal one another's bundles, but this doesn't seem like a problem at all in our system, though it may be for others.
Some more work definitely needs to be done on this though.
Related
Discussion
Anonymous
As you say, the rationale for that check is to prevent tasks from stealing one another's bundles; that may or may not be important. An alternative to ditching the check would be to allow a task to use an endpoint for sending bundles even it if it doesn't "own" it for the purposes of receiving bundles; that would address the near-term problem (the bping reception thread would be the owner of the endpoint) while we think about whether the check itself is worth preserving.
Agreed; there are a whole spectrum of options.
I think this will impact more than just bping, but bping was the
only thing I've noticed it on so far.
My current hack preserves the log message warning, so an admin could
see that perhaps something odd is happening, but suppresses the
early return of an error code, and lets the rest of the logic complete.
I don't have much instinct on what the most correct behavior is or
what other people would prefer. I think this is an oddity that only
impacts vxworks (and maybe RTEMS?) due to its model of implementing
the pthread library.
On 8/21/2014 11:07 AM, Scott Burleigh wrote:
--
Wes Eddy
MTI Systems
Related
Bugs:
#54Right, it's a general problem, not just a bping issue; it happens to show up in bping, but tweaking only bping is too narrow a solution. It's also general problem, not just a VxWorks problem; it happens to show up in VxWorks, but tweaking only the VxWorks task management adaptation is too narrow a solution. Detaching bundle sourcing from endpoint ownership is a general solution, I think, but ditching the endpoint ownership concept is an even more general solution. Maybe too general, though; that's the point I'm still not clear on - is that constraint on endpoint access operationally valuable or not? Anybody on the mailing list have any thoughts on this?
Scott
From: Wes Eddy [mailto:wesley-eddy@users.sf.net]
Sent: Thursday, August 21, 2014 9:01 AM
To: [ion-dtn:bugs]
Subject: [ion-dtn:bugs] Re: #54 vxworks pthread task IDs
Agreed; there are a whole spectrum of options.
I think this will impact more than just bping, but bping was the
only thing I've noticed it on so far.
My current hack preserves the log message warning, so an admin could
see that perhaps something odd is happening, but suppresses the
early return of an error code, and lets the rest of the logic complete.
I don't have much instinct on what the most correct behavior is or
what other people would prefer. I think this is an oddity that only
impacts vxworks (and maybe RTEMS?) due to its model of implementing
the pthread library.
On 8/21/2014 11:07 AM, Scott Burleigh wrote:
As you say, the rationale for that check is to prevent tasks from
stealing one another's bundles; that may or may not be important. An
alternative to ditching the check would be to allow a task to use an
endpoint for sending bundles even it if it doesn't "own" it for the
purposes of receiving bundles; that would address the near-term problem
(the bping reception thread would be the owner of the endpoint) while we
think about whether the check itself is worth preserving.
[bugs:#54]http://sourceforge.net/p/ion-dtn/bugs/54 http://sourceforge.net/p/ion-dtn/bugs/54 vxworks pthread
task IDs
Status: open
Group: 3.2.1
Created: Thu Aug 21, 2014 02:23 PM UTC by Wes Eddy
Last Updated: Thu Aug 21, 2014 02:23 PM UTC
Owner: nobody
Using ION 3.1.3:
When running on vxworks, bping is not able to receive the responses to
its pings. This may be symptomatic of a larger problem with the
sm_TaskId functions and how vxworks treats pthreads however.
When using bping on vxworks 6.3, the filter in libbp.c around line 550
("Can't receive: not owner of endpoint.") is triggered, because the way
that the sm_TaskId functions seem to operate on vxworks pthreads.
bping spawns two threads, one for sending bundles, and one for
receiving. The receiving and sending threads wind up with different
sm_TaskIdSelf() results, and the receiving thread specifically has a
different TaskId than the thread that bound and owns the endpoint, which
is what prevents that check in libbp.c line 550 from succeeding.
The temporary solution I'm using (rather than tinkering with the sm_*
functions) is to only return failure in that libbp.c check #ifndef
VXWORKS, but this is kind of a hack. The only downside I see is that
potentially tasks can steal one another's bundles, but this doesn't seem
like a problem at all in our system, though it may be for others.
Some more work definitely needs to be done on this though.
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/ion-dtn/bugs/54/https://sourceforge.net/p/ion-dtn/bugs/54
https://sourceforge.net/p/ion-dtn/bugs/54
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/https://sourceforge.net/auth/subscriptions
https://sourceforge.net/auth/subscriptions
--
Wes Eddy
MTI Systems
[bugs:#54]http://sourceforge.net/p/ion-dtn/bugs/54 vxworks pthread task IDs
Status: open
Group: 3.2.1
Created: Thu Aug 21, 2014 02:23 PM UTC by Wes Eddy
Last Updated: Thu Aug 21, 2014 03:07 PM UTC
Owner: nobody
Using ION 3.1.3:
When running on vxworks, bping is not able to receive the responses to its pings. This may be symptomatic of a larger problem with the sm_TaskId functions and how vxworks treats pthreads however.
When using bping on vxworks 6.3, the filter in libbp.c around line 550 ("Can't receive: not owner of endpoint.") is triggered, because the way that the sm_TaskId functions seem to operate on vxworks pthreads.
bping spawns two threads, one for sending bundles, and one for receiving. The receiving and sending threads wind up with different sm_TaskIdSelf() results, and the receiving thread specifically has a different TaskId than the thread that bound and owns the endpoint, which is what prevents that check in libbp.c line 550 from succeeding.
The temporary solution I'm using (rather than tinkering with the sm_* functions) is to only return failure in that libbp.c check #ifndef VXWORKS, but this is kind of a hack. The only downside I see is that potentially tasks can steal one another's bundles, but this doesn't seem like a problem at all in our system, though it may be for others.
Some more work definitely needs to be done on this though.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ion-dtn/bugs/54/https://sourceforge.net/p/ion-dtn/bugs/54
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/https://sourceforge.net/auth/subscriptions
Related
Bugs:
#54Addressed by feature branch bug-0054-endpoint-ownership: adding a new bp_open_source function that returns a BpSAP that can be used for bundle transmission by any number of tasks but not for reception (which is still restricted to a single task that has called bp_open). This function also enables newly sourced bundles to be "detained" in storage even after transmission, so that the application may track, suspend/resume, or cancel them; only when this detention feature is invoked will the address of a newly created bundle be returned to the application when bp_send is called.