Fwd: Unable to follow the connection of pn_pipe() with file descriptor used for poll()

[Sanny <sa...@gmail.com>]

1. I am porting qpid proton c for MQX OS. Now I don't have the equivalent's
to pipe() nor poll().

2.I understand I need to do something similar to Windows.

*Questions:*

*1> I am  unable to follow the code flow used in porting for Windows, I see
two sockets being created to simulated the pipe ends. Further on not fully
able to grasp. Will there be a document to understand the flow? It would be
grateful if someone can help in the right direction?*

*2> What is the significance of the selector module? What is the data that
is added to the selector's datastructure and how this aids the sending of
the AMQP packet?*



Thanks in Advance

Regards

Re: Fwd: Unable to follow the connection of pn_pipe() with file descriptor used for poll()

[sanddune008 <sa...@gmail.com>]

Thanks....

I am still working on to figure out how the selectable read , write events
are triggered  , Please let me if some one can help me with the flow.

> How does the event trigger to get out of the looping in 
> "pn_selector_next()".....
  In my current code base *"while (selector->current < size) {"* is failing.

> Significance of pn_wait()? I mean how the poll() function is dependent on
> triggering events.





--
View this message in context: http://qpid.2158936.n2.nabble.com/Fwd-Unable-to-follow-the-connection-of-pn-pipe-with-file-descriptor-used-for-poll-tp7634615p7634876.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.

Re: Fwd: Unable to follow the connection of pn_pipe() with file descriptor used for poll()

[Fraser Adams <fr...@blueyonder.co.uk>]

Hello Sanny,
I know nothing about MQX OS so there is a limit to how much I can help you.

I ported proton to JavaScript which has similar complications, though 
the workarounds are likely different.

Firstly the good news is that pipe() is only actually used for 
pn_messenger_interrupt() in JavaScript I actually just didn't bother to 
implement that method as it makes little sense in an asynchronous 
environment. The JavaScript binding uses emscripten 
https://github.com/kripken/emscripten/wiki to compile from C to 
JavaScript and has a JavaScript library to emulate many of the posix C 
network API calls, for the case of pipe() the call is IIRC actually a 
null/do nothing implementation these two lines in messenger.c

     // Explicitly initialise pipe file descriptors to invalid values in 
case pipe
     // fails, if we don't do this m->ctrl[0] could default to 0 - which 
is stdin.
     m->ctrl[0] = -1;
     m->ctrl[1] = -1;

are down to me as a result of that - in the JavaScript pipe does indeed 
fail and this explicitly ensures I get invalid file descriptors 
(otherwise you can see spurious activity on stdin!!??#)


The bad news is that proton messenger uses poll for much more than just 
the pipe, the selector module is actually mainly used for handling 
activity on the main network sockets handling the AMQP transfer.

The way I dealt with this stuff can be found in 
proton-c/bindings/javascript/module.js mostly in _pumpOnce how it works 
(roughly) is that it receives events from JavaScript WebSocket event 
handlers (onopen, onmessage, onclose etc.) It actually tries to emulate 
the flow of class Pump in tests/python/proton_tests/messenger.py (which 
is another place to look for ideas), my code does use a "poll" of sorts, 
emscripten actually emulates poll in that it maintains flags 
corresponding to WebSocket activity on the emulated file descriptors, of 
course poll is a blocking call so you wouldn't want to use it in the 
normal way on an async system hence why I call it when I receive any 
WebSocket event it's really used to map back to the actual (emulated) 
file descriptor that triggered the event.

I have to say that stuff was all pretty fiddly and a bit specific to the 
environment that you are working with and it took me quite a while to 
get it working, but it might at least give you a few pointers.

Regards,
Frase


On 27/11/15 05:42, Sanny wrote:
> 1. I am porting qpid proton c for MQX OS. Now I don't have the equivalent's
> to pipe() nor poll().
>
> 2.I understand I need to do something similar to Windows.
>
> *Questions:*
>
> *1> I am  unable to follow the code flow used in porting for Windows, I see
> two sockets being created to simulated the pipe ends. Further on not fully
> able to grasp. Will there be a document to understand the flow? It would be
> grateful if someone can help in the right direction?*
>
> *2> What is the significance of the selector module? What is the data that
> is added to the selector's datastructure and how this aids the sending of
> the AMQP packet?*
>
>
>
> Thanks in Advance
>
> Regards
>