in reply to Re^3: Forking Clients
in thread Forking Clients

Yes, sorry for overlooking that. I have a few general questions more about understanding and extending this concept.

This is a rather simple proof of concept, the final implementation would involve the rpc function being called from multiple different places, possibly simultaneously, in this case I want the caller to wait until its response is ready, when it is it should grab it and go on, while the other callers continue to wait.

In Pseudo code it would be some thing like this:

function rpc
    do thread and queueing stuff in here
end rpc


function blah
  rpc(IP, port2, command)
  look at queue see if your result is there
  if it is not
     wait
  else
     do other stuff with the info
end blah

function blee
  rpc(IP, port1, command)
  look at queue see if your result is there
  if it is not
     wait
  else
     do other stuff with the info
end blah

[download]

These function may very well call rpc at the same time, they will always use different port numbers. How would I go about using the queue to determine if my information is back, since in each instance of the call I won't know how many ports I have open, it only knows about the port it was told to use. Should I dequeue check the port/result and if it doesn't match enqueue it again?

I really appreciate all your help.

Replies are listed 'Best First'.
Re^5: Forking Clients
by BrowserUk (Patriarch) on Oct 15, 2008 at 18:31 UTC
    it only knows about the port it was told to use. Should I dequeue check the port/result and if it doesn't match enqueue it again?

    No. What you are describing probably requires a completely different architecture to your OP code. But you first need to ask yourself a few questions.

    The first problem is how are you ever going to get to call blee() once you've called blah()?

    Ie. In the code that calls blah() and blee(), as you've described it in this post, once you call the first of these, it is going to block until it gets it's results, so you won't be able to call the second until the first has finished.

    So how can "These function may very well call rpc at the same time," be so?

    Once you decide how the top level of your code is going to operate, then you can decide how best to structure it?

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

      Good point, and maybe I am approaching this the wrong way. But here is what I would like to do.

      I have a main program, which has a bunch of things it needs to do. From it I want to spawn off a function that will make a call, that function will wait for a response. The main program itself should not wait for it to come back, it should continue on spawning off other functions, or doing basic prints or function calls.

      When the spawned off function is done with its work,it would be great if there would be some interrupt which would let me know that it is, if needed I could periodically call a piece of code to check to see if its done.

      Does this explain it better?

      I really appreciate your help with this.

[reply]
        Does this explain it better?

        Kinda. Ignoring how it is implemented for now, let's assume that your functions blah() & blee() etc. are written so that they support the following api: 

        my $blah = blah( ... );
my $blee = blee( ... );
...

if( $blah ) { 
    my @blahResults = $blah->();
    ...
}

...
if( $blee ) {
    my @bleeResults = $blee->();
    ...
}

        [download]

        What does your main program look like?

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
        What does the function you spawn off do with the response? Must the main program know what that spawned process has done or that it was successful?

        If you only need to know that the spawned process is complete, then that's pretty easy. A non-blocking wait could help with that if you plan on rolling your own.

        If, however, the main program needs to know what's going on in the spawned processes then you have a more complicated issue.

        I recommend you get and read a book by Stevens. Perhaps UNIX Network Programming, Volume 2, Second Edition: Interprocess Communications, Prentice Hall, 1999 (ISBN 0130810819) or maybe Advanced Programming in the UNIX Environment, Addison-Wesley, 1992 (ISBN 0201563177).

        Before you protest that you're not programming in C or that you're not using Unix, let me point out that the concepts are the same. The Unix family of OSes is the home of sockets, C, Perl, several forms of IPC, regular expressions as a computational tool, and more. Perl borrows heavily from C, Unix, and Unix-borne tools in its concepts. If you know Perl and how IPC works on Unix, then save for a few caveats about other OSes you're mostly set to do IPC in Perl.

[reply]

In Section Seekers of Perl Wisdom