Relay() me PLEASE!

Hi All,

I won’t bore everyone with the bass ackwards chain of events and
happenstance that got me to the point of having to ask what I’m about to…
But, I will apologize in advance, for this all seeming a little crazy :wink:

Attached is the source for a program that tests Relay(). Here’s the usage
message:

Test Relay() functionality. Optionally across vc/node boundaries

================
Usage:
relayme [options]

options
-t D|R|S Task Type… Default:
D
D - Dispatcher: A single/initial task that is the parent of
all
R & S tasks. Relays messages from S tasks to R tasks.
R - Receiver: Task that receives & replies to test messages.
S - Sender: Task that iteratively sends messages to the D
task.
The header record in each message instructs the D task to
Relay() the message to a specific R task ID. Successive
messages cycle through all available/specified R task
IDs.
-R node# Specify node to spin R tasks off on. Default:
0
-S node# Specify node to spin S tasks off on. Default:
0
-r # Number of R tasks to spawn or spawned. Default:
1
-s # Number of S tasks to spawn. Default:
1
-n # Number of message iterations for each S task. Default:
1
-i # Index (ID) of R|S task. Default:
0
-M “string” String to be sent as message data. Default:
N/A
-F file File whose contents are to be sent as message data. Default:
N/A

=========================

Yes, I know… In the documentation for Relay() it is stated that Relay()
does not work across node boundaries. But, what I’ve discovered with my
test program is… That’s not entirely true.

Spinning the Sender Task off on another node with the Dispatcher & Receiver
on the same/original node, WORKS! and works quite well, I might add. I’ve
had multiple instances merrily passing around 38K+ size messages on/between
several different OS releases and on/between a variety of hardware.

Spinning the Receiver Task off to another node, regardless of where the
Sender is spun off to, causes a kernel panic on the originating node 8-(

Is this expected behavior? Is it safe to assume that the Sender case that
works, really does work… and is perhaps a supported behavior? Oddly, I
don’t really care about the kernel panic case… Well, except that it is
good to know that this is something you really don’t ever want to do on
purpose :wink:

Any help would be appreciated.

TIA
Rob


begin 666 relayme.c
M+R@97@Z<V5T(‘1S/30@<W<]-#H-“B\O($%U=&AO<CH@4F]B($AE;0T*#0HC
M:69D968@7U]54T%'10T*#0I497-T(%)E;&%Y*“D@9G5N8W1I;VYA;&ET>2X@
M($]P=&EO;F%L;'D@86-R;W-S('9C+VYO9&4@8F]U;F1A<FEE<PT*#0I5<V%G
M93H-“B5#(%LJ;W!T:6]N<RI=#0H-“BIO<'1I;VYS*@T*(” M=”!$?%)\4R @
M(” @5&%S:R!4>7!E+BXN(” @(" @(" @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @($1E9F%U;‘0Z($0-“B @(” @(" @(" @(" @($0@+2!$:7-P
M871C:&5R.B!!(’-I;F=L92]I;FET:6%L(‘1A<VL@=&AA="!I<R!T:&4@<&%R
M96YT(&]F(&%L; T*(" @(" @(" @(" @(" @(" @(%(@)B!3(‘1A<VMS+B @
M4F5L87ES(&UE<W-A9V5S(&9R;VT@4R!T87-K<R!T;R!2(‘1A<VMS+@T*(" @
M(" @(" @(" @(" @4B M(%)E8V5I=F5R.B!487-K(‘1H870@<F5C96EV97,@
M)B!R97!L:65S(‘1O(‘1E<W0@;65S<V%G97,N#0H@(" @(" @(" @(" @("!3
M(“T@4V5N9&5R.B!487-K('1H870@:71E<F%T:79E;‘D@<V5N9’,@;65S<V%G
M97,@=&@=&AE($0@=&%S:RX-“B @(” @(” @(" @(" @(" @("!4:&4@:&5A
M9&5R(’)E8V]R9"!I;B!E86-H(&UE<W-A9V4@:6YS=’)U8W1S(‘1H92!$(‘1A
M<VL@=&-“B @(” @(" @(" @(" @(" @("!296QA>2@I(‘1H92!M97-S86=E
M(‘1O(&$@<W!E8VEF:6,@4B!T87-K($E$+B @4W5C8V5S<VEV90T*(" @(" @
M(" @(" @(" @(" @(&UE<W-A9V5S(&-Y8VQE(‘1H<F]U9V@@86QL(&%V86EL
M86)L92]S<&5C:69I960@4B!T87-K($E$<RX-“B @+5(@;F]D92,@(” @(%-P
M96-I9GD@;F]D92!T;R!S<&EN(%(@=&%S:W,@;V9F(&]N+B @(" @(" @(" @
M(" @("!$969A=6QT.B P#0H@(“U3(&YO9&4C(” @("!3<&5C:69Y(&YO9&4@
M=&@<W!I;B!3(‘1A<VMS(&]F9B!O;BX@(" @(" @(" @(" @(" @1&5F875L
M=#H@, T*(" M<B C(" @(" @(" @3G5M8F5R(&]F(%(@=&%S:W,@=&@<W!A
M=VX@;W(@<W!A=VYE9"X@(" @(" @(" @(" @($1E9F%U;‘0Z(#$-“B @+7,@
M(R @(” @(" @($YU;6)E<B!O9B!3(‘1A<VMS(‘1O(’-P87=N+B @(" @(" @
M(" @(" @(" @(" @(" @("!$969A=6QT.B Q#0H@(“UN(”,@(" @(" @("!.
M=6UB97(@;V8@;65S<V%G92!I=&5R871I;VYS(&9O<B!E86-H(%,@=&%S:RX@
M(" @(" @1&5F875L=#H@,0T*(" M:2 C(" @(" @(" @26YD97@@$E$2!O
M9B!2?%,@=&%S:RX@(" @(" @(" @(" @(" @(" @(" @(" @(" @($1E9F%U
M;‘0Z(# -“B @+4T@(G-T<FEN9R(@(%-T<FEN9R!T;R!B92!S96YT(&%S(&UE
M<W-A9V4@9&%T82X@(” @(" @(" @(" @(" @("!$969A=6QT.B!.+T$-“B @
M+48@9FEL92 @(” @($9I;&4@=VAO<V4@8V]N=&5N=’,@87)E(‘1O(&)E(’-E
M;G0@87,@;65S<V%G92!D871A+B!$969A=6QT.B!.+T$-"@T
(V5N9&EF#0H-
M"B-I;F-L=61E(#QS=&1I;RYH/@T
(VEN8VQU9&4@/’-T9&QI8BYH/@T*(VEN
M8VQU9&4@/‘5N:7-T9"YH/@T*(VEN8VQU9&4@/’-T9&%R9RYH/@T*(VEN8VQU
M9&4@/’-T<FEN9RYH/@T*(VEN8VQU9&4@/’!R;V-E<W,N:#X-"B-I;F-L=61E
M(#QT:6UE+F@^#0HC:6YC;‘5D92 \9F-N=&PN:#X-"B-I;F-L=61E(#QS>7,O
M<W1A="YH/@T*(VEN8VQU9&4@/’-Y<R]K97)N96PN:#X-"B-I;F-L=61E(#QS
M>7,O<V5N9&UX+F@^#0H-"B-D969I;F4@7U](15)%7U)>W!R:6YT9B@@(DQI
M;F4Z(“5D7&XB+”!?7TQ)3D5?7R I.WT@+R@1F]R($1E8G5G9VEN9PT*#0IT
M>7!E9&5F(’-T<G5C="![#0H)=5]S:&]R= ED7VED+ D)+R@1&5S=&EN871I
M;VX@=&%S:R!)1 T*"0D)<U]I9#L)“2\O(%-O=7)C92 @(” @(‘1A<VL@240-
M"GT@=&AD<E]T.PD)"0DO+R!497-T($UE<W-A9V4@2&5A9&5R(’)E8V]R9 T*
M#0IT>7!E9&5F(’-T<G5C="![#0H)=&AD<E]T.PD)"0DO+R!497-T($UE<W-A
M9V4@2&5A9&5R(’)E8V]R9 T*"6QO;F<);7-I>F4["0DO+R!-97-S86=E($1A
M=&$@4VEZ90T*?2!T;7-G7W0["0D)“2\O(%1E<W0@365S<V%G92!R96-O<F0@
M*$1A=&$@9F]L;&]W<R!I;B!M<VEZ92!B;&]B0T#0IS=&%T:6,@8VAA<@D)
M5%1Y<&4@/2 G1”<[“2\O(%1A<VL@5’EP90T*<W1A=&EC(&EN= D)240@(” @
M/2 P.PD)+R@5&%S:R!)1 T*<W1A=&EC(&EN= D)3G5M4B @/2 Q.PD)+R@
M3G5M8F5R(&]F(%)E8V5I=F4@5&%S:W,-"G-T871I8R!I;G0)“4YU;5,@(#T@
M,3L)“2\O($YU;6)E<B!O9B!396YD(” @(%1A<VMS#0IS=&%T:6,@:6YT"0E.
M=6U-(” ](#$["0DO+R!.=6UB97(@;V8@365S<V%G97,@<&5R(%-E;F0@5&%S
M:PT*<W1A=&EC(&YI9%]T"5)N;V1E(#T@,#L)"2\O($YO9&4@240@9F]R(%)E
M8V5I=F4@5&%S:W,-“G-T871I8R!N:61?= E3;F]D92 ](# [“0DO+R!.;V1E
M($E$(&9O<B!396YD(” @(%1A<VMS#0IS=&%T:6,@:6YT"0E&:7)S=” ](# [
M"0DO+R!&;&%G(&9I<G-T(&QO9VET*“D@8V%L;” H<V@;&]G(&ES(‘1R=6YC
M871E9"D-"G-T871I8R!L;VYG"0E-<VEZ92 ](#!,.PD)+R@365S<V%G92!$
M871A(%-I>F4-“G-T871I8R!C:&%R"0DJ36)U9CL)“0DO+R!-97-S86=E($1A
M=&$@0G5F9F5R#0IS=&%T:6,@8VAA<@D)D9N86UE.PD)“2\O($UE<W-A9V4@
M1&%T82!&:6QE($YA;64-”@T
<W1A=&EC('9O:60@;&]G:70H(&-H87(@F9M
M="P@+BXN("D-"GL-"FEN= D);V9L86=S(#T@3U]74D].3%E\3U]#4D5!5’Q/
M7T%04$5.1#L-"FEN= D)9F0[#0II;G0)"7-Z.PT
8VAA<@EB=69;.#!=.PT*
M=&EM95]T"70#0IS=’)U8W0@=&T@G1M.PT=F%?;&ES= EA<F=S.PT*#0H)
M=&EM92@@)G0@*3L-"@ET;2
G0@3L-"@ES>B ](%]B
M<’)I;G1F
”!B=68L(#@P#0H)“0D)(“P@(B4N,F0Z)2XR9#HE+C)D(”(L('1M
M+3YT;5]H;W5R+”!T;2T^=&U?;6EN+”!T;2T^=&U?<V5C#0H)"0D)(“D[#0H)
M=F%?<W1A<G0H(&%R9W,L(&9M=” I.PT*“7-Z(“L](%]V8G!R:6YT9B@@8G5F
MW-Z+" X,“US>BP@9FUT+”!A<F=S("D[#0H)=F%?96YD”!A<F=S(“D[#0H-
M”@EI9@DH($9I<G-T(“D@>PT*“0EO9FQA9W,@?#T@3U]44E5.0SL-”@D)1FER
M<W0@/2 P.PT*“7T-”@T*“6EF"2@@&9D(#T@;W!E;B@@(G)E;&%Y;64N;&]G
M(BP@;V9L86=S+" P-C8P("DI(#T]("TQ("D@>PT
"0EP<FEN=&8H(”(E8ULE
M+C)D73H@;W!E;B!O9B G<F5L87EM92YL;V<G($9!24Q%1#H@)7-<;B5S(@T*
M"0D)(” L(%14>7!E+”!)1"P@<W1R97)R;W(H(&5R<FYO(“DL(&)U9@T*“0D)
M(” I.PT*“0EE>&ET*”!%6$E47T9!24Q54D4@3L-"@E]#0H)=W)I=&4H(&9D
M+"!B=68L(’-Z("D[#0H)8VQO<V4H(&9D(“D[#0I]#0H-@T
<W1A=&EC('9O
M:60@4E]T87-K*”!V;VED("D-"GL-"G!I9%]T"6UY<&ED(#T@9V5T<&ED*"DL
M#0H)“7)P:60[#0IT;7-G7W0);7-G.PT8VAA<@DJ;6)U9CL-"FEN= D);7AC
M;G0@/2 Q+ T
"0EM8VYT(” ](# [#0IS=’)U8W0@7VUX9F5R7V5N=’)Y(&UX
M6S)=.PT*#0H);65M<V5T*" F;7-G+" P+"!S:7IE;V8H(&US9R I(“D[#0H)
M7W-E=&UX*” F;7A;,%TL("9M<V<L(’-I>F5O9B@@;7-G(“D@3L-"@T"6EF
M"2@@37-I>F4@/B P3” I(‘L-"@D);6)U9B ](&-A;&QO8R@@,2P@37-I>F4@
M3L-"@D)7W-E=&UX" F;7A;,5TL(&UB=68L($US:7IE(“D[#0H)“6UX8VYT
M(#T@,CL-”@E]#0H-@EL;V=I="@@(E);)2XR9%TZ(%-405)4(“T@;7EP:60]
M)2XU9”!P&ED/24N-60@37-IF4])6QD7&XB#0H)“2 L($E$+”!M>7!I9"P@
M9V5T<’!I9"@I+"!-<VEZ90T*“0D@3L-"@T"7=H:6QE*” H<G!I9" ](%)E
M8V5I=F5M>"@@,“P@;7AC;G0L(&UX(“DI(#X@,” I('L-”@D):68)"!M<V<N
M;7-I>F4@(3T@37-I>F4@2![#0H)“0EL;V=I=”@@(E);)2XR9%TZ(%)#5B4N
M,V0@+2!R<&ED/24N-60@(&1?:60])2XR=2!S7VED/24N,G4B#0H)“0D)(” @
M(B M($US:7IE($9!24Q%1" E;&0@(3T@)6QD7&XB#0H)"0D)("P@240L("LK
M;6-N=“P@<G!I9"P@;7-G+F1?:60L(&US9RYS7VED+”!-<VEZ92P@;7-G+FUS
M:7IE#0H)"0D)("D[#0H)“0EB<F5A:SL-”@D)?2!E;’-E#0H)"6EF"2@@;7-G
M+FUS:7IE(#T](#!,("D@>PT
"0D);&]G:70H(")26R4N,F1=.B!20U8E+C-D
M(“T@<G!I9#TE+C5D(”!D7VED/24N,G4@<U]I9#TE+C)U7&XB#0H)"0D)("P@
M240L("LK;6-N="P@<G!I9"P@;7-G+F1?:60L(&US9RYS7VED#0H)"0D)("D[
M#0H)"7T@96QS90T
"0EI9@DH(&UE;6-M<"@@;6)U9BP@36)U9BP@37-I>F4@
M2 A/2 P("D@>PT"0D);&]G:70H(")26R4N,F1=.B!20U8E+C-D(“T@<G!I
M9#TE+C5D(”!D7VED/24N,G4@<U]I9#TE+C)U(“T@36)U9B!.3U0@3TM<;B(-
M”@D)“0D@+”!)1"P@RMM8VYT+"!R<&ED+"!M<V<N9%]I9"P@;7-G+G-?:60-
M"@D)"0D@3L-"@D)"6)R96%K.PT"0E](&5L<V4@>PT
"0D);&]G:70H(")2
M6R4N,F1=.B!20U8E+C-D(“T@<G!I9#TE+C5D(”!D7VED/24N,G4@<U]I9#TE
M+C)U(“T@36)U9B!/2UQN(@T*“0D)“2 L($E$+” KVUC;G0L(’)P:60L(&US
M9RYD7VED+"!M<V<N<U]I9 T
"0D)“2 I.PT*“0E]#0H-@D)+R@1FQI<”!3
M;W5R8V4@)B!$97-T:6YA=&EO;B!F;W(@4F5P;'DH0T"0EM<V<N9%]I9” ]
M(&US9RYS7VED.PT*“0EM<V<N<U]I9” ]($E$.PT*#0H)“6QO9VET*” B4ELE
M+C)D73H@4E!9)2XS9” M(’)P:60])2XU9" @9%]I9#TE+C)U(’-?:60])2XR
M=5QN(@T*"0D)("P@240L(&UC;G0L(’)P:60L(&US9RYD7VED+"!M<V<N<U]I
M9 T*“0D)(“D[#0H-@D):68)"!297!L>6UX”!R<&ED+"!M>&-N=“P@;7@@
M2 (# @2![#0H)“0EL;V=I=”@@(E);)2XR9%TZ(%)E<&QY’)P:60])2XU
M9"D@1D%)3$5$.B E<UQN(@T
"0D)“2 L($E$+”!R<&ED+”!S=’)E<G)O<B@@
M97)R;F@0T"0D)“2 I.PT*“0D)97AI=”@@15A)5%]&04E,55)%(“D[#0H)
M"7T-”@T*“0EI9@DH($US:7IE(“D-”@D)“6UE;7-E=”@@;6)U9BP@,“P@37-I
M>F4@3L-"@E]#0H-"@EL;V=I="@@(E);)2XR9%T@+2!$;VYE+EQN(BP@240@
M
3L-“GT-”@T*#0IS=&%T:6,@=F]I9”!37W1A<VLH('9O:60@0T>PT*<&ED
M7W0);7EP:60@/2!G971P:60H2P-"@D)<’!I9#L-"FEN= D):3L-“G1M<V=?
M= EM<V<#0IC:&%R"2IM8G5F.PT*:6YT"0EM>&-N=" “6UC;G0@
M(#T@,#L-“G-T<G5C=”!?;7AF97)?96YT<GD@<VUX6S)=+”!R;7A;,ET[#0H-
M”@EM96US970H(“9M<V<L(# L(’-I>F5O9B@@;7-G(“D@3L-"@E?<V5T;7@H
M("9S;7A;,%TL(“9M<V<L(’-I>F5O9B@@;7-G(“D@3L-"@E?<V5T;7@H(“9R
M;7A;,%TL(“9M<V<L(’-I>F5O9B@@;7-G(“D@3L-"@T"6EF"2@@37-I>F4@
M/B P3” I('L-”@D);6)U9B @(” @(#T@8V%L;&]C
” Q+”!-<VEZ92 I.PT

M"0EM>&-N=” @(” @/2 R.PT
"0EM<V<N;7-I>F4@/2!-<VEZ93L-”@D)7W-E
M=&UX*” F<VUX6S%=+"!-8G5F+"!-<VEZ92 I.PT*“0E?<V5T;7@H(“9R;7A;
M,5TL(&UB=68L($US:7IE(“D[#0H)?0T*#0H)+R@5V%I=”!F;W(@9&%D(‘1O
M(’)E;&5A<V4@=7,N+BX-”@EP<&ED(#T@4F5C96EV92@@,“P@3E5,3"P@,” I
M.PT*“5)E<&QY*”!P<&ED+”!.54Q,+" P(“D[#0H-@EL;V=I="@@(E-;)2XR
M9%TZ(%-405)4(“T@;7EP:60])2XU9”!P<&ED/24N-61<;B(L($E$+"!M>7!I
M9"P@<’!I9" I.PT*#0H)9F]R("@@:2 ](# [(&D@/"!.=6U-.R!IRL@2![
M#0H)"6US9RYS7VED(#T@240[#0H)"6US9RYD7VED(#T@:2 E($YU;5([#0H)
M"6EF"2@@37-I>F4@0T"0D);65M<V5T
"!M8G5F+" P+"!-<VEZ92 I.PT

M#0H)“6QO9VET*” B4ULE+C)D73H@4TY$)2XS9" M(’!P:60])2XU9" @9%]I
M9#TE+C)U(’-?:60])2XR=5QN(@T*“0D)(“P@240L(“LK;6-N=“P@<’!I9"P@
M;7-G+F1?:60L(&US9RYS7VED#0H)“0D@3L-"@T"0EI9@DH(%-E;F1M>”@@
M<’!I9"P@;7AC;G0L(&UX8VYT+”!S;7@L(’)M>” I(#P@,” I('L-”@D)“6QO
M9VET*” B4ULE+C)D73H@4V5N9"AP<&ED/24N-60I($9!24Q%1#H@)7-<;B(-
M"@D)“0D@+”!)1"P@<’!I9"P@<W1R97)R;W(H(&5R<FYO(“D-”@D)“0D@3L-
M"@D)"65X:70H($58251?1D%)3%5212 I.PT
"0E]#0H)“0T*“0EI9@DH(&US
M9RYM<VEZ92 A/2!-<VEZ92 I('L-”@D)“6QO9VET*” B4ULE+C)D73H@4E!9
M)2XS9” M(’!P:60])2XU9” @9%]I9#TE+C)U(’-?:60])2XR=2(-"@D)“0D@
M(” B(“T@37-I>F4@1D%)3$5$(“5L9” A/2 E;&1<;B(-”@D)“0D@+”!)1"P@
M;6-N=“P@<’!I9"P@;7-G+F1?:60L(&US9RYS7VED+”!-<VEZ92P@;7-G+FUS
M:7IE#0H)“0D)(“D[#0H)“0EB<F5A:SL-”@D)?2!E;’-E#0H)“6EF"2@@;7-G
M+FUS:7IE(#T](#!,(“D@>PT*“0D);&]G:70H(”)36R4N,F1=.B!24%DE+C-D
M(“T@<’!I9#TE+C5D(”!D7VED/24N,G4@<U]I9#TE+C)U7&XB#0H)“0D)(“P@
M240L(&UC;G0L(’!P:60L(&US9RYD7VED+”!M<V<N<U]I9 T*“0D)“2 I.PT*
M"0E](&5L<V4-”@D):68)"!M96UC;7 H(&UB=68L($UB=68L($US:7IE(“D@
M(3T@,” I('L-"@D)"6QO9VET
” B4ULE+C)D73H@4E!9)2XS9” M(’!P:60]
M)2XU9” @9%]I9#TE+C)U(’-?:60])2XR=2 M($UB=68@3D]4($]+7&XB#0H)
M"0D)(“P@240L(&UC;G0L(’!P:60L(&US9RYD7VED+”!M<V<N<U]I9 T*“0D)
M"2 I.PT*“0D)8G)E86L[#0H)“7T@96QS92![#0H)“0EL;V=I=”@@(E-;)2XR
M9%TZ(%)0624N,V0@+2!P<&ED/24N-60@(&1?:60])2XR=2!S7VED/24N,G4@
M+2!-8G5F($]+7&XB#0H)“0D)(“P@240L(&UC;G0L(’!P:60L(&US9RYD7VED
M+”!M<V<N<U]I9 T*“0D)“2 I.PT*“0E]#0H)?0T*#0H);&]G:70H(”)36R4N
M,F1=(“T@1&]N92Y<;B(L($E$(“D[#0I]#0H-@T*<W1A=&EC('9O:60@1%]T
M87-K*”!V;VED(“D-“GL-“G!I9%]T"6UY<&ED(#T@9V5T<&ED*“DL#0H)“7)P
M:60[#0IC:&%R"2IA<F=S6S$R73L-“G!I9%]T"2IR;&ES=“P-”@D)G-L:7-T
M.PT
=&AD<E]T"6AD<CL-“FEN= D);6UA>” ]($YU;5,@B!.=6U-.PT:6YT
M"0EI.PT8VAA<@EI9%LX72P-"@D);G);.%TL#0H)“6YM6S$P73L-”@T"49I
M<G-T(#T@,3L-”@EL;V=I=”@@(D0H<&ED/24N-60I(“T@4U1!4E0@+2!2;F]D
M93TE9”!3;F]D93TE9”!.=6U2/25D($YU;5,])60@3G5M33TE9%QN(@T*“0D@
M+”!M>7!I9"P@4FYO9&4L(%-N;V1E+”!.=6U2+”!.=6U3+”!.=6U-#0H)“2 I
M.PT*#0H)+R@06QL;V-A=&4@=&AE(%(@=&%S:W,@<&ED+W9I9”!L:7-T#0H)
M:68)" H<FQI<W0@/2!C86QL;V,H($YU;5(L(’-I>F5O9B@@<&ED7W0@2 I
M
2 ]/2!.54Q,("D@>PT
"0EL;V=I=”@@(D0@+2!R;&ES=”!A;&QO8R!&04E,
M140@+2 E<UQN(BP@<W1R97)R;W(H(&5R<FYO(“D@3L-"@D)97AI="@@15A)
M5%]&04E,55)%("D[#0H)?0T
#0H)+R@06QL;V-A=&4@=&AE(%,@=&%S:W,@
M<&ED+W9I9”!L:7-T#0H):68)" H<VQI<W0@/2!C86QL;V,H($YU;5,L(’-I
M>F5O9B@@<&ED7W0@2 I2 ]/2!.54Q,("D@>PT
"0EL;V=I=”@@(D0@+2!S
M;&ES=”!A;&QO8R!&04E,140@+2 E<UQN(BP@<W1R97)R;W(H(&5R<FYO(“D@
M3L-"@D)97AI="@@15A)5%]&04E,55)%(“D#0H)?0T*#0H)+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O#0H)+R@4W!I;B!O9F8@4B!487-K<RXN
M+@T*"2\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+PT*#0H)87)G<ULP
M72
R96QA>6UE(CL-”@EA<F=S6S%=(#T@(BUT(CL-"@EA<F=S6S)=(#T@
M(E(B.PT
"6%R9W-;,UT@/2 B+6DB.PT*“6%R9W-;-%T@/2!I9#L-”@EI9@DH
M($US:7IE(“D@>PT*“0EI9@DH($9N86UE(“D@>PT*“0D)87)G<ULU72 ](”(M
M1B([#0H)“0EA<F=S6S9=(#T@1FYA;64[#0H)“7T@96QS92![#0H)“0EA<F=S
M6S5=(#T@(BU-(CL-”@D)“6%R9W-;-ET@/2!-8G5F.PT*“0E]#0H)“6%R9W-;
M-UT@/2!.54Q,.PT*“7T@96QS92![#0H)“6%R9W-;-5T@/2!.54Q,.PT*“7T-
M”@T*“69O<B H(&D@/2 P.R!I(#P@3G5M4CL@:2LK(“D@>PT*“0ES<’)I;G1F
M*”!I9"P@(B5D(BP@:2 I.PT*#0H)“7)L:7-T6VE=(#T-@D)<6YX7W-P87=N
M*” P+”!.54Q,+”!2;F]D92P@+3$L(“TQ+” P+”!A<F=S6S!=+”!A<F=S+”!E
M;G9I<F]N+”!.54Q,+” M,2 I.PT*#0H)“6EF"2@@<FQI<W1;:5T@/#T@,” I
M('L-”@D)“6QO9VET*” B1” M(’-P87=N(&]F(%);)2XR9%T@1D%)3$5$(“T@
M)7-<;B(L(&DL(’-T<F5R<F]R*”!E<G)N;R I(“D[#0H)“0EE>&ET*”!%6$E4
M7T9!24Q54D4@3L-"@D)?0T#0H)“6QO9VET*” B1” M(’-P87=N(%);)2XR
M9%T@<&ED+W9I9#TE+C5D7&XB+”!I+”!R;&ES=%MI72 I.PT*“7T-”@T*“2\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+PT*“2\O(%-P:6X@;V9F(%,@
M5&%S:W,N+BX-”@DO+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R-”@T*
M"6%R9W-;,ET@/2 B4R([#0H):2 ]“2@@37-I>F4@2 _(#<@.B U.PT"6%R
M9W-;:2LK72 ](”(M<B([#0H)87)G<UMIRM=(#T@;G([#0H)87)G<UMIRM=
M(#T@(BUN(CL-”@EA<F=S6VDKUT@/2!N;3L-"@EA<F=S6VDKUT@/2!.54Q,
M.PT*#0H)<W!R:6YT9B@@;G(L(”(E9”(L($YU;5(@3L-"@ES<’)I;G1F”!N
M;2P@(B5D(BP@3G5M32 I.PT*#0H)9F]R(”@@:2 ](# [(&D@/”!.=6U3.R!I
MRL@2![#0H)“7-P<FEN=&8H(&ED+” B)60B+"!I(“D[#0H-@D)<VQI<W1;
M:5T@/0T
"0EQ;GA?<W!A=VXH(# L($Y53$PL(%-N;V1E+" M,2P@+3$L(# L
M(&%R9W-;,%TL(&%R9W,L(&5N=FER;VXL($Y53$PL("TQ(“D[#0H-@D):68)
M
"!S;&ES=%MI72 /2 P(“D@>PT*“0D);&]G:70H(”)$(“T@<W!A=VX@;V8@
M4ULE+C)D72!&04E,140@+2 E<UQN(BP@:2P@<W1R97)R;W(H(&5R<FYO(“D@
M3L-"@D)"65X:70H($58251?1D%)3%5212 I.PT"0E]#0H-@D);&]G:70H
M(”)$(“T@<W!A=VX@4ULE+C)D72!P:60O=FED/24N-61<;B(L(&DL(’-L:7-T
M6VE=(“D[#0H)?0T*#0H)+R@4F5L96%S92!3(%1A<VMS+BXN#0H-”@EF;W(@
M*”!I(#T@,#L@:2 ($YU;5,[(&DKR I(‘L-"@D)4V5N9"@@<VQI<W1;:5TL
M($Y53$PL($Y53$PL(# L(# @3L-"@E]#0H-"@DO+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R-"@DO+R!296QA>2!,;V]P+BXN#0H)+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O
M+R\O+R\O+R\O+R\O+R\O+R\O+R\O#0H-"@EF;W(@
"!I(#T@,#L@:2 (&UM
M87@(&DKR I('L-"@D):68)" H<G!I9" E8V5I=F4H(# L("9H9’(L
M(’-I>F5O9B@@:&1R(“D@2D@/#T@," I('L-"@D)"6QO9VET” B1" M(%)E
M8V5I=F4H
2!&04E,140@+2 E<UQN(BP@<W1R97)R;W(H(&5R<FYO(“D@3L-
M"@D)"65X:70H($58251?1D%)3%5212 I.PT
"0E]#0H-@D);&]G:70H(”)$
M.B!214Q!62@@)2XU9"T^)2XU9" I(" @(&1?:60])2XR=2!S7VED/24N,G4@
M7&XB#0H)“0D@+”!R<&ED+"!R;&ES=%MH9’(N9%]I9%TL(&AD<BYD7VED+"!H
M9’(N<U]I9 T*“0D)(“D[#0H-@D):68)"!H9’(N9%]I9" ^/2!.=6U2("D@
M>PT
"0D);&]G:70H(”)$.B!D7VED(&]U="!O9B!R86YG92Y<;B(@3L-"@D)
M"65X:70H($58251?1D%)3%5212 I.PT
"0E]#0H-"@D):68)"!296QA>2@@
M<G!I9"P@<FQI<W1;:&1R+F1?:61=(“D@/” P("D@>PT
"0D);&]G:70H(")$
M(“T@4F5L87DH2!&04E,140@+2 E<UQN(BP@<W1R97)R;W(H(&5R<FYO("D@
M
3L-”@D)“65X:70H($58251?1D%)3%5212 I.PT*“0E]#0H)?0T*#0H)<VQE
M97 H(#(@3L)“2\O($QE=”!L87-T(&UE<W-A9V4@8VQE87(-"@T"6QO9VET
M*” B1” M($1O;F4N7&XB(“D[#0I]#0H-@T*<W1A=&EC(‘9O:60@<V5T7V9D
M871A*"!C:&%R("IF;F%M92 I#0I[#0II;G0)9F0[#0IS=’)U8W0@<W1A="!S
M8CL-"@T*“6EF"2@@&9D(#T@;W!E;B@@9FYA;64L($]?4D1/3DQ9("DI(#T]
M("TQ("D@>PT
"0EP<FEN=&8H(”)%<G)O<B!O<&5N:6YG("<E<R<Z(“5S7&XB
M+”!F;F%M92P@<W1R97)R;W(H(&5R<FYO2 I.PT"0EE>&ET*"!%6$E47T9!
M24Q54D4@3L-"@E]#0H)#0H):68)"!F<W1A="@@9F0L(“9S8B I(#T](“TQ
M(“D@>PT*“0EP<FEN=&8H(”)#86XG=”!F<W1A=”@I(”<E<R<Z(“5S7&XB+”!F
M;F%M92P@<W1R97)R;W(H(&5R<FYO2 I.PT"0EE>&ET*"!%6$E47T9!24Q5
M4D4@3L-"@E]#0H-"@EI9@DH("A-8G5F(#T@;6%L;&]C"!S8BYS=%]S:7IE
M(“DI(#T]($Y53$P@2![#0H)“7!R:6YT9B@@(D-A;B=T(&UA;&QO8R@I($UB
M=68@9F]R(”<E<R<Z(“5S7&XB+”!F;F%M92P@<W1R97)R;W(H(&5R<FYO
2 I
M.PT*“0EE>&ET*”!%6$E47T9!24Q54D4@3L-"@E]#0H-"@E-<VEZ92 ](’-B
M+G-T7W-I>F4[#0H)1FYA;64@/2!F;F%M93L-"@T
"7)E860H(&9D+”!-8G5F
M+"!-<VEZ92 I.PT*#0H)8VQO<V4H(&9D(“D[#0I]#0H-@T*=F]I9"!M86EN
M*"!I;G0@87)G8RP@8VAA<B JF%R9W8@0T>PT:6YT"0EC.PT*#0H)=VAI
M;&4H(“AC(#T@9V5T;W!T*”!A<F=C+"!A<F=V+" B=#I2.E,Z<CIS.FXZ:3I&
M.DTZ(B I2 A/2 M,2 I('L-"@D)<W=I=&-H"!C(“D@>PT*“0EC87-E(”=T
M)SH)5%1Y<&4@/2 J;W!T87)G.PD)8G)E86L[#0H)“6-A<V4@)U(G.@E2;F]D
M92 ](&%T;VDH(&]P=&%R9R I.PEB<F5A:SL-”@D)8V%S92 G4R<Z"5-N;V1E
M(#T@871O:2@@;W!T87)G(“D[“6)R96%K.PT*“0EC87-E(”=R)SH)3G5M4B @
M/2!A=&]I*”!O<'1A<F<@3L)8G)E86L[#0H)“6-A<V4@)W,G.@E.=6U3(” ]
M(&%T;VDH(&]P=&%R9R I.PEB<F5A:SL-"@D)8V%S92 G;B<Z"4YU;4T@(#T@
M871O:2@@;W!T87)G("D["6)R96%K.PT
"0EC87-E(”=I)SH)240@(” @/2!A
M=&]I*"!O<'1A<F<@3L)8G)E86L[#0H)“6-A<V4@)T8G.@ES971?9F1A=&$H
M(&]P=&%R9R I.PEB<F5A:SL-”@D)8V%S92 G32<Z#0H)“0E-8G5F(” ](&]P
M=&%R9SL-"@D)"4US:7IE(#T@<W1R;&5N
"!-8G5F("D@R Q.PT"0D)8G)E
M86L[#0H)"61E9F%U;'0Z#0H)"0EP<FEN=%]U<V%G92@@87)G=B I.PT*“0E]
M#0H)?0T*#0H)+R@4F5L87DH2!F<F]M('9C('1O('9C(&-A=7-E<R!N;V1E
M(&QO8VMU<"$-"@T
"6EF"2@@4FYO9&4@(3T@,” F)B!3;F]D92 A/2 P("D@
M>PT*“0EP<FEN=&8H(”)4:&4@+5(@)B M4R!O<'1I;VYS(&%R92!M=71U86QL
M>2!E>&-L=7-I=F4N7&XB(“D[#0H)“65X:70H($58251?1D%)3%5212 I.PT*
M"7T-”@T*“7-W:71C:”@@5%1Y<&4@2![#0H)8V%S92 G1"<Z"41?=&%S:R@@
M
3L)8G)E86L[#0H)8V%S92 G4B<Z"5)?=&%S:R@@*3L)8G)E86L[#0H)8V%S
M92 G4R<Z"5-?=&%S:R@@3L)8G)E86L[#0H)?0T#0H)97AI=”@@15A)5%]3
…54-#15-3("D[#0I]#0H
end

PING! Perhaps I shouldn’t have apologized first?

I would really appreciate an answer as to whether the Sender case that
apparently works, was designed to work and can be expected to work in future
OS releases i.e. isn’t just a fluke/bug/undocumented feature. Or if there
are some problems/side affects associated with it that I may not be aware
of.

OK, I’ll come clean…
I’m responsible for an aging/legacy transaction acquisition QNX 4 based
production system that can benefit in a big way from this Relay() “feature”.
In fact, one sub-system within it has been (accidentally) taking advantage
of “this feature” for several years now, with no problems that I’m aware of.
I’m a little embarrassed that this “feature” was discovered by accident in a
production environment, but the plain true is, it’s a natural and efficient
fit in the system architecture. Far superior on several levels to any of
the possible alternatives. And, there is now a need to intentionally expand
the dependency on this feature to other sub-systems. But, I would feel a
lot better about it if I could get some positive feedback/reinforcement :wink:

TIA,
-Rob

“Rob” <rob@spamyouself.com> wrote in message
news:bil8fm$f71$1@inn.qnx.com

Hi All,

I won’t bore everyone with the bass ackwards chain of events and
happenstance that got me to the point of having to ask what I’m about
to…
But, I will apologize in advance, for this all seeming a little crazy > :wink:

Attached is the source for a program that tests Relay(). Here’s the usage
message:

Test Relay() functionality. Optionally across vc/node boundaries

================
Usage:
relayme [options]

options
-t D|R|S Task Type…
Default:
D
D - Dispatcher: A single/initial task that is the parent of
all
R & S tasks. Relays messages from S tasks to R tasks.
R - Receiver: Task that receives & replies to test
messages.
S - Sender: Task that iteratively sends messages to the D
task.
The header record in each message instructs the D task
to
Relay() the message to a specific R task ID.
Successive
messages cycle through all available/specified R task
IDs.
-R node# Specify node to spin R tasks off on.
Default:
0
-S node# Specify node to spin S tasks off on.
Default:
0
-r # Number of R tasks to spawn or spawned.
Default:
1
-s # Number of S tasks to spawn.
Default:
1
-n # Number of message iterations for each S task.
Default:
1
-i # Index (ID) of R|S task.
Default:
0
-M “string” String to be sent as message data.
Default:
N/A
-F file File whose contents are to be sent as message data.
Default:
N/A

=========================

Yes, I know… In the documentation for Relay() it is stated that Relay()
does not work across node boundaries. But, what I’ve discovered with my
test program is… That’s not entirely true.

Spinning the Sender Task off on another node with the Dispatcher &
Receiver
on the same/original node, WORKS! and works quite well, I might add. I’ve
had multiple instances merrily passing around 38K+ size messages
on/between
several different OS releases and on/between a variety of hardware.

Spinning the Receiver Task off to another node, regardless of where the
Sender is spun off to, causes a kernel panic on the originating node 8-(

Is this expected behavior? Is it safe to assume that the Sender case that
works, really does work… and is perhaps a supported behavior? Oddly, I
don’t really care about the kernel panic case… Well, except that it is
good to know that this is something you really don’t ever want to do on
purpose > :wink:

Any help would be appreciated.

TIA
Rob

Rob <rob@spamyouself.com> wrote in message news:bj54fv$423$1@inn.qnx.com

I would really appreciate an answer as to whether the Sender case that
apparently works, was designed to work and can be expected to work in
future
OS releases i.e. isn’t just a fluke/bug/undocumented feature. Or if there
are some problems/side affects associated with it that I may not be aware
of.

It isn’t designed to work, and the relay kernel call isn’t aware of some of
the special conditions concering VIDs (ie. buffer growth etc) which can
occur.

Is it safe to assume that the Sender case that
works, really does work… and is perhaps a supported behavior?

Nope, sorry the gear isn’t in there to safely do what you want. If you’ve
done testing and feel it’s ‘good enough’, that is your call; but we can’t
support that (that’s why it’s doc’d the way it is).

-Adam

Rob <rob@spamyouself.com> wrote:
R > PING! Perhaps I shouldn’t have apologized first?

R > I would really appreciate an answer as to whether the Sender case that
R > apparently works, was designed to work and can be expected to work in future
R > OS releases i.e. isn’t just a fluke/bug/undocumented feature. Or if there
R > are some problems/side affects associated with it that I may not be aware
R > of.

I’m aware of the negitive responce in te nest post.

But if it does work currently and your comfortable with it,
I wouldn’t worry too much about future releases of QNX4.
The lid is pretty much nailed down on the coffin.

OK, Understood… Not officially supported. Thanks for your candor :wink:

You mentioned special conditions concerning VIDs and buffer growth… Could
it be that the Send case works (and the other cases don’t) because buffer
growth is handled before the Relay() call i.e. in the Send() across the
network from the Sender process to the Dispatcher process? I did test this
with relatively large messages (38K+) and intentionally did not pre-alloc a
VID buffer.

Are there any more VID special conditions I might need to worry about? Just
trying to measure the risk.

And… Bill, Thanks for your response too. For the record… This
particular “dead horse” is still making us a significant chunk of change.
Neither I nor any of my associates are quite ready to bury it any time
soon… Although we are working on the next generation.

-Rob

“Adam Mallory” <amallory@qnx.com> wrote in message
news:bj5aa5$c2o$1@nntp.qnx.com

Rob <> rob@spamyouself.com> > wrote in message
news:bj54fv$423$> 1@inn.qnx.com> …
I would really appreciate an answer as to whether the Sender case that
apparently works, was designed to work and can be expected to work in
future
OS releases i.e. isn’t just a fluke/bug/undocumented feature. Or if
there
are some problems/side affects associated with it that I may not be
aware
of.

It isn’t designed to work, and the relay kernel call isn’t aware of some
of
the special conditions concering VIDs (ie. buffer growth etc) which can
occur.

snip
Is it safe to assume that the Sender case that
works, really does work… and is perhaps a supported behavior?

Nope, sorry the gear isn’t in there to safely do what you want. If you’ve
done testing and feel it’s ‘good enough’, that is your call; but we can’t
support that (that’s why it’s doc’d the way it is).

-Adam

Rob <rob@spamyouself.com> wrote:

R > And… Bill, Thanks for your response too. For the record… This
R > particular “dead horse” is still making us a significant chunk of change.
R > Neither I nor any of my associates are quite ready to bury it any time
R > soon… Although we are working on the next generation.

I agree. If QNX4 meets your needs it is a much superior product.
I.E. Faster and requires MUCH less memory.

Rob <rob@spamyouself.com> wrote in message news:bj5f42$bdi$1@inn.qnx.com

OK, Understood… Not officially supported. Thanks for your candor > :wink:

You mentioned special conditions concerning VIDs and buffer growth…
Could
it be that the Send case works (and the other cases don’t) because buffer
growth is handled before the Relay() call i.e. in the Send() across the
network from the Sender process to the Dispatcher process? I did test
this
with relatively large messages (38K+) and intentionally did not pre-alloc
a
VID buffer.

In the case of the sender being on another node, the message has already
transfered and it does ‘just happen to work’. In the case of the reciever
on another node, there isn’t any gear to make a remote sender (or even local
for that matter) to ‘do the right thing’ for the target vid, since it
assumes it’s a pid.

Are there any more VID special conditions I might need to worry about?
Just
trying to measure the risk.

Things like the vid becoming invalid (timeout, idle out etc) might get you
some ‘strange’ behaviour where you could attempt a relay from message in
buffer associated with a VC which has disappeared (ie. kernel panic).

-Adam

Bill Caroselli <qtps@earthlink.net> wrote in message
news:bj5ag5$7jc$1@inn.qnx.com

I’m aware of the negitive responce in te nest post.

It wasn’t negative, just the gear isn’t there.

But if it does work currently and your comfortable with it,
I wouldn’t worry too much about future releases of QNX4.
The lid is pretty much nailed down on the coffin.

I wouldn’t get that dramatic about it. Bugs are fixed, issues are
addressed, new netdrivers get ported - hardly a ‘dead horse’.

-Adam

Bill Caroselli <qtps@earthlink.net> wrote in message
news:bj5fse$be7$1@inn.qnx.com

I agree. If QNX4 meets your needs it is a much superior product.
I.E. Faster and requires MUCH less memory.

Given a much more limited scope, reduced functionality, and more constrained
target audience, sure QNX4 is a superior product (if that is your yardstick
when measure superiority). IMHO, it’s hard to actually compare the two in a
really fair way (and it’s not like I’m not a QNX4 supporter here :slight_smile: )

Just my $0.02, I’m sure others will disagree :slight_smile:

-Adam

Hi Adam

I didn’t mean to make it a religious argument. I agree that QNX4 has
significant limitations. I do use threads in QNX6. It makes things
easier then they were in Q4.

But if QNX4 does what someone needs it to do, it is at least faster.

QSSL touts multi-platform as the big deal with QNX6. But most people
who are developing a product are only developing it for one platform,
whatever that is. On the other hand anyone selling software as their
product, like QSSK, would very much desire te multi-platform capability.

I do regret that I haven’t yet had a project that would cost justify
getting into SMP on QNX. Many years ago I worked for a company that
received real-time stock market data and did analysis on that data.
When the market was slow we were able to do very in-depth analysis.
When the market got busy we were only able to do some very basic live
analysis. That application would have benefitted from as many CPUs
as we could throw at it. We did use multiple nodes, both for fault
tolerance and to distribute the load, but what you gain in multiple
CPUs across the network you loose because your multiple CPSs are
across the network. Of course then we were also still limited to
10 Mbps.

QNX4 was great for what it did. QNX6 is great for what it does.
It’s an issue of using the right tool for the right job.


Adam Mallory <amallory@qnx.com> wrote:
AM > Bill Caroselli <qtps@earthlink.net> wrote in message
AM > news:bj5ag5$7jc$1@inn.qnx.com

I’m aware of the negitive responce in te nest post.

AM > It wasn’t negative, just the gear isn’t there.

But if it does work currently and your comfortable with it,
I wouldn’t worry too much about future releases of QNX4.
The lid is pretty much nailed down on the coffin.

AM > I wouldn’t get that dramatic about it. Bugs are fixed, issues are
AM > addressed, new netdrivers get ported - hardly a ‘dead horse’.

AM > -Adam

“Adam Mallory” <amallory@qnx.com> wrote in message
news:bj5is4$lqs$1@nntp.qnx.com

Bill Caroselli <> qtps@earthlink.net> > wrote in message
news:bj5ag5$7jc$> 1@inn.qnx.com> …

I’m aware of the negitive responce in te nest post.

It wasn’t negative, just the gear isn’t there.

But if it does work currently and your comfortable with it,
I wouldn’t worry too much about future releases of QNX4.
The lid is pretty much nailed down on the coffin.

I wouldn’t get that dramatic about it. Bugs are fixed, issues are
addressed, new netdrivers get ported - hardly a ‘dead horse’.

Don’t forget to mention PCCARD!

-Adam

Bill Caroselli <qtps@earthlink.net> wrote in message
news:bj5js2$eef$1@inn.qnx.com

I didn’t mean to make it a religious argument. I agree that QNX4 has
significant limitations. I do use threads in QNX6. It makes things
easier then they were in Q4.

Nor, I - I just dislike blanket statements that QNX4 is a superior product
than QNX6, and feel that it doesn’t really reflect reality.

But if QNX4 does what someone needs it to do, it is at least faster.

Depends - IP networking is definately faster in QNX6… but anyways…

QNX4 was great for what it did. QNX6 is great for what it does.
It’s an issue of using the right tool for the right job.

Absolutely the same feeling here Bill - right tool, right job. :slight_smile:

-Adam

Mario Charest postmaster@127.0.0.1 wrote in message
news:bj5j8e$e3q$1@inn.qnx.com

Don’t forget to mention PCCARD!

Opps :wink:

-Adam

“Adam Mallory” <amallory@qnx.com> wrote in message
news:bj5imo$lfe$1@nntp.qnx.com

Rob <> rob@spamyouself.com> > wrote in message
news:bj5f42$bdi$> 1@inn.qnx.com> …
OK, Understood… Not officially supported. Thanks for your candor > :wink:

You mentioned special conditions concerning VIDs and buffer growth…
Could
it be that the Send case works (and the other cases don’t) because
buffer
growth is handled before the Relay() call i.e. in the Send() across the
network from the Sender process to the Dispatcher process? I did test
this
with relatively large messages (38K+) and intentionally did not
pre-alloc
a
VID buffer.

In the case of the sender being on another node, the message has already
transfered and it does ‘just happen to work’. In the case of the reciever
on another node, there isn’t any gear to make a remote sender (or even
local
for that matter) to ‘do the right thing’ for the target vid, since it
assumes it’s a pid.

OK, makes sense… And I suppose if a Reply() (in the Sender case) happened
to be significantly bigger than any previous Send(), that could also cause
problems?

Are there any more VID special conditions I might need to worry about?
Just
trying to measure the risk.

Things like the vid becoming invalid (timeout, idle out etc) might get you
some ‘strange’ behaviour where you could attempt a relay from message in
buffer associated with a VC which has disappeared (ie. kernel panic).

In this particular systems architecture … The Relay() call is always
immediately after the Receive() in the equivalent of the Dispatcher and the
Reply() is also immediate in the equivalent of the Receiver. All out-bound
messaging traffic from the Dispatcher’s node is process to process, no
Relay() calls involved.

Just wondering… What constitutes a VID timeout, idle out, etc. ? Can a
VID be automagicly torn down even when both of the connected processes are
still active/functioning normally?

Worst case I can think of… What if… the remote Sender just happened to
die in-between the Receive() in the Dispatcher and the Reply() in the
Receiver? What would be the difference between this and a Sender on the
same node as the Dispatcher? Aren’t we just dealing with a local pid in
either case, the local vid is a pid, is it not? Either the Relay() in the
Dispatcher or the Receive()/Reply() in the Receiver should just simply fail
since the source pid is now invalid (not cause a kernel panic, god help
us!)? I’ll see if I can put together a test case.

Thanks again,

-Rob

snip

-Adam

Rob <rob@spamyouself.com> wrote in message news:bj5n1j$gcr$1@inn.qnx.com

OK, makes sense… And I suppose if a Reply() (in the Sender case)
happened
to be significantly bigger than any previous Send(), that could also cause
problems?

Anything that requires action because we’re communicating over a VC could be
problematic (buffer growth etc).

In this particular systems architecture … The Relay() call is always
immediately after the Receive() in the equivalent of the Dispatcher and
the
Reply() is also immediate in the equivalent of the Receiver. All
out-bound
messaging traffic from the Dispatcher’s node is process to process, no
Relay() calls involved.

Just wondering… What constitutes a VID timeout, idle out, etc. ? Can a
VID be automagicly torn down even when both of the connected processes are
still active/functioning normally?

There is no real correlation between a process that is ‘active/functioning
normally’ and activity over a VC. If there isn’t any communication over the
VC for a while, it gets torn down due to ‘idle out’. My main concern is
that network activity happens asyncronous to the Relay kernel call and
things can change behind my back

Worst case I can think of… What if… the remote Sender just happened to
die in-between the Receive() in the Dispatcher and the Reply() in the
Receiver? What would be the difference between this and a Sender on the
same node as the Dispatcher? Aren’t we just dealing with a local pid in
either case, the local vid is a pid, is it not?

Yes - but the message passing S/R/R kernel calls all have gear in them to
deal with VIDs. The Relay() call does not, and makes internal transfer
calls which already assume it’s safe to make the transfer.

Either the Relay() in the
Dispatcher or the Receive()/Reply() in the Receiver should just simply
fail
since the source pid is now invalid (not cause a kernel panic, god help
us!)? I’ll see if I can put together a test case.

Ok, but there are no promises on what we can do about it if it crashes since
you’re going against the documented behaviour.

-Adam

Thank you very much Adam. This discussion has been extremely helpful. I’ve
got a lot of other things on my plate right now, so it will be a few days
before I can get around to trying out some test cases. I’ll be back next
week :wink:

Just a few more thoughts below…

“Adam Mallory” <amallory@qnx.com> wrote in message
news:bj7caj$r4f$1@nntp.qnx.com

Rob <> rob@spamyouself.com> > wrote in message
news:bj5n1j$gcr$> 1@inn.qnx.com> …

OK, makes sense… And I suppose if a Reply() (in the Sender case)
happened
to be significantly bigger than any previous Send(), that could also
cause
problems?

Anything that requires action because we’re communicating over a VC could
be
problematic (buffer growth etc).

In this particular systems architecture … The Relay() call is always
immediately after the Receive() in the equivalent of the Dispatcher and
the
Reply() is also immediate in the equivalent of the Receiver. All
out-bound
messaging traffic from the Dispatcher’s node is process to process, no
Relay() calls involved.

Just wondering… What constitutes a VID timeout, idle out, etc. ? Can
a
VID be automagicly torn down even when both of the connected processes
are
still active/functioning normally?

There is no real correlation between a process that is ‘active/functioning
normally’ and activity over a VC. If there isn’t any communication over
the
VC for a while, it gets torn down due to ‘idle out’. My main concern is
that network activity happens asyncronous to the Relay kernel call and
things can change behind my back

I understand what you’re saying, BUT… In the Sender case… The Sender
process does after all Send() to the Dispatcher. And, the Dispatcher does
Receive() at least part of the message before doing the Relay(). That part
of all this is a documented (and supported) feature of the QNX4 messaging
API. In order for the Send()/Receive() to succeed the VC does have to be
valid. Further, since success means the VC is active, I don’t really
understand how an ‘idle out’ would be applicable?? Or why the VC would then
ever be torn down in the micro seconds between The Receive() and Relay()
calls (apart from the Sender dying). Yes, If the Dispatcher sat on the
Receive() for a significant amount of time before doing the Relay(), ‘idle
out’ could be a problem. I will avoid doing/allowing that :wink:

Worst case I can think of… What if… the remote Sender just happened
to
die in-between the Receive() in the Dispatcher and the Reply() in the
Receiver? What would be the difference between this and a Sender on the
same node as the Dispatcher? Aren’t we just dealing with a local pid in
either case, the local vid is a pid, is it not?

Yes - but the message passing S/R/R kernel calls all have gear in them to
deal with VIDs. The Relay() call does not, and makes internal transfer
calls which already assume it’s safe to make the transfer.

Either the Relay() in the
Dispatcher or the Receive()/Reply() in the Receiver should just simply
fail
since the source pid is now invalid (not cause a kernel panic, god help
us!)? I’ll see if I can put together a test case.

Ok, but there are no promises on what we can do about it if it crashes
since
you’re going against the documented behaviour.

Regarding what could happen after the Relay(). You mentioned that the
Sender case “just works” because the message has already been transferred to
the Dispatchers node. In this context… Is it logical to assume that once
all this has survived the Relay() call, the internal workings of the S/R/R
kernel calls will protect against anything catastrophic (kernel panic)
happening?

Undocumented behavior, eh… Any programmer worth his salt has learned how
to read between the lines… and not believe everything he reads :wink:

Thanks again,

-Rob



-Adam

Rob <rob@spamyouself.com> wrote in message news:bj7tqt$65s$1@inn.qnx.com

I understand what you’re saying, BUT… In the Sender case… The Sender
process does after all Send() to the Dispatcher. And, the Dispatcher does
Receive() at least part of the message before doing the Relay(). That
part
of all this is a documented (and supported) feature of the QNX4 messaging
API. In order for the Send()/Receive() to succeed the VC does have to be
valid.

Yes, in order for the “sender” to transition from SEND_BLOCK to REPLY_BLOCK,
he must have done the transfer and the VC must have been valid at that time.

Further, since success means the VC is active, I don’t really
understand how an ‘idle out’ would be applicable?? Or why the VC would
then
ever be torn down in the micro seconds between The Receive() and Relay()
calls (apart from the Sender dying).

Probably can’t, but a lot of time can pass between the time you unblock
from Receive() and the Replay(), an OS can’t bank on the fact the user
should call them back to back, not to mention that preemption can make
that time between the two calls become quite long.

Regarding what could happen after the Relay(). You mentioned that the
Sender case “just works” because the message has already been transferred
to
the Dispatchers node. In this context… Is it logical to assume that
once
all this has survived the Relay() call, the internal workings of the S/R/R
kernel calls will protect against anything catastrophic (kernel panic)
happening?

Once the target of the relay has indeed received the message, and replied to
the sender (and the reply made it over the network) it is logical. I won’t
guarantee it though, since there could be scenarios I haven’t thought of.

Undocumented behavior, eh… Any programmer worth his salt has learned how
to read between the lines… and not believe everything he reads > :wink:

Well this isn’t ‘between the lines’, this is ignoring the lines that clearly
say not to do something. Reminds me of the lesson on touching the hot
stove…

-Adam

“Adam Mallory” <amallory@qnx.com> wrote in message
news:bj837e$oee$1@nntp.qnx.com

Rob <> rob@spamyouself.com> > wrote in message
news:bj7tqt$65s$> 1@inn.qnx.com> …

I understand what you’re saying, BUT… In the Sender case… The
Sender
process does after all Send() to the Dispatcher. And, the Dispatcher
does
Receive() at least part of the message before doing the Relay(). That
part
of all this is a documented (and supported) feature of the QNX4
messaging
API. In order for the Send()/Receive() to succeed the VC does have to
be
valid.

Yes, in order for the “sender” to transition from SEND_BLOCK to
REPLY_BLOCK,
he must have done the transfer and the VC must have been valid at that
time.

Further, since success means the VC is active, I don’t really
understand how an ‘idle out’ would be applicable?? Or why the VC would
then
ever be torn down in the micro seconds between The Receive() and Relay()
calls (apart from the Sender dying).

Probably can’t, but a lot of time can pass between the time you
unblock
from Receive() and the Replay(), an OS can’t bank on the fact the user
should call them back to back, not to mention that preemption can make
that time between the two calls become quite long.

snip

Regarding what could happen after the Relay(). You mentioned that the
Sender case “just works” because the message has already been
transferred
to
the Dispatchers node. In this context… Is it logical to assume that
once
all this has survived the Relay() call, the internal workings of the
S/R/R
kernel calls will protect against anything catastrophic (kernel panic)
happening?

Once the target of the relay has indeed received the message, and replied
to
the sender (and the reply made it over the network) it is logical. I
won’t
guarantee it though, since there could be scenarios I haven’t thought of.

Undocumented behavior, eh… Any programmer worth his salt has learned
how
to read between the lines… and not believe everything he reads > :wink:

Well this isn’t ‘between the lines’, this is ignoring the lines that
clearly
say not to do something. Reminds me of the lesson on touching the hot
stove…

Hey now! I’ve already apologized for this being a little crazy :wink: And I
could be making a big deal out of the difference between doing something
ignorant/stupid and just getting burned… and having the whole damn stove
blow up on you and taking out the house to boot! … But I won’t :slight_smile:

If it’s any comfort, I’ve decided to put a simple “vcrelay” process (on the
Dispatcher node) in-between the Sender and the Dispatcher. Your statement
that “… a lot of time can pass…” reminded me of the number one rule
for our systems design… “Nothing can hold up the Dispatcher”. In our
systems design, the Dispatcher does more than just Relay() messages.
Depending on the message type, there are instances where it will directly
Reply() to the Sender. Doing that over the network, introduces a
significantly higher probability of delaying the Dispatcher (due to network
congestion or other problems). So, besides helping to eliminate the
possibility of a kernel panic , the ‘vcrelay’ process will also help
eliminate possible Dispatcher delays and allows all the previously defined
message flow in the architecture of our systems to stay in place, including
the Dispatcher Relay() feature. It’s a good fit, that’s both documented and
supported.

Thanks again for all your help,

-Rob

-Adam

Rob <rob@spamyouself.com> wrote in message news:bjimcv$rvu$1@inn.qnx.com

Hey now! I’ve already apologized for this being a little crazy > :wink: > And I
could be making a big deal out of the difference between doing something
ignorant/stupid and just getting burned… and having the whole damn stove
blow up on you and taking out the house to boot! … But I won’t > :slight_smile:

I wasn’t trying to rude, just furthering the ‘reading between the lines’
analogy. I happen to agree that relay should actually enforce the use of
real pids rather than vids.

If it’s any comfort, I’ve decided to put a simple “vcrelay” process (on
the
Dispatcher node) in-between the Sender and the Dispatcher. Your statement
that “… a lot of time can pass…” reminded me of the number one rule
for our systems design… “Nothing can hold up the Dispatcher”. In our
systems design, the Dispatcher does more than just Relay() messages.
Depending on the message type, there are instances where it will directly
Reply() to the Sender. Doing that over the network, introduces a
significantly higher probability of delaying the Dispatcher (due to
network
congestion or other problems). So, besides helping to eliminate the
possibility of a kernel panic , the ‘vcrelay’ process will also help
eliminate possible Dispatcher delays and allows all the previously defined
message flow in the architecture of our systems to stay in place,
including
the Dispatcher Relay() feature. It’s a good fit, that’s both documented
and
supported.

Sounds like you’ve come up with a good idea, and one that you can rely on :slight_smile:

Thanks again for all your help,

NP, thank you for you patience.

-Adam