in reply to Re: Split process->check ->and run Parallel
in thread Split process->check ->and run Parallel

I think this is something similar to what I wrote in reply to Corion's post

For example, when the text file is complete, the file "REPORT.TXT" would appear in the output directory. When the excel file is complete, then "REPORT.XLS" would appear in the output directory. If P2 wants to report an error, then "REPORT.FAILED" would appear in the output directory. Here are the 2 reasons:

1) This approach may not suffice when there is a possibility of other files or users able to create/write files to a specific directory under the same name that process 'p1' is expecting

2) If the file is being written to after it is created, then process 'p1' should ensure that file to be used ( output.txt ) is indeed complete ( that the file handles over the file no more is valid )
  • Comment on Re^2: Split process->check ->and run Parallel

Replies are listed 'Best First'.
Re^3: Split process->check ->and run Parallel
by Corion (Patriarch) on Dec 24, 2008 at 10:47 UTC

    It would enabled us to help you better if you had mentioned all these prerequirements in your original post instead of after you get solutions. Of course, if other users can create a file with the same name as the "P2" program, then you have other problems on your system, because then nobody will know whose report got generated and whose report got overwritten.

[reply]
      Sorry, I didn't create the original post.

      I was just going through the post and the replies. I felt the solutions posted were not optimal and that's why commented.

      Please do let me know if this is something that should not be done. I don't think you would say 'yes' for this. :)

      If there is a possibility of other process creating the same file, then process 'p2' should be aware of such a filename being existing already or the file that it had opened is being overwritten by some other process
[reply]
        matrixmadhan:

        There's no reason to be sorry, I think it's great that you noticed a problem and pointed it out. I can't speak for Corion, but I suspect I know what happened--there's a tendency for a new member to give a vague question, and then reply to the answers with things like "but that won't work because I need <insert new requirement here>!", which should have been stated as a requirement in the original question. Since my posts occasionally run overlong (especially when I'm on vacation! Yahoo!) the OP scrolled off the top of the screen, so he likely didn't have the OPs name on the screen, and your replies did kind of look like that sort of "new requirements" feel to it.

        I can't think of a good segue between the section above, and the rest of this node (which I wrote earlier). Sorry for the 'speed bump' between sections.

        Every monk has their own strategies for selecting questions to answer and the style of answer to offer. You'll find that a well-written question with a good attempt at a solution and sample data will frequently get a more specific answer than a quick question with little effort put into it. My answering style differs depending on (a) how bored I am, (b) how generous I'm feeling that day, (c) how interesting the question is, (d) the phase of the moon, and (e) the current price (yuan) of Oolong tea in China. 8^)

        In this case it felt like it might be a homework problem. In general, I don't want to hand an answer to a homework problem over, as it doesn't teach the poster much. But when a half-dozen monks each provide various hints, the poster gets the opportunity to figure out how to put the hints together into an outline[3] and turn it into code--a great way for us to share experience and the poster to flex some programming muscles. So when a problem feels like it might be a homework problem, I tend to just give some hints and/or try to organize their thoughts with a few details thrown in.

        Regarding your suggestion that using the presence of output.txt as a signal is dangerous[1]--that's true. But I'm surprised that you didn't offer a hint to one of the well-known solutions to that objection: create the file with a temporary name, and rename it to the final name after it's completely generated. There are, of course, solutions to your other objections (name clashes, etc.)

        Finally, when you read a node, you choose (or create) a quick mental model of the person writing the question, and then write your answer for that person[2]. In this particular case, my model of the questioner was of a programmer who already has the code to generate the reports (because of the timings provided for the reports) and probably has related problems solved. Additionally, the question felt fairly specific (if a bit wide-ranging).

        [1] Stated best in your reply to Corion.

        [2] Which is why having multiple answers is so beneficial. No-one is going to have a complete/accurate mental model of the writer. So instead, you get better coverage with multiple answers.

        [3] One of the reasons I didn't bother to give an example of fork, since Corion had already done so. (The other reason being that I've never used fork in perl.)

        ...hyperverbosicus

        Update: Repaired misspelling of Corion's name ... I'm so sorry! (Thanks to kile for the catch!)

[reply]
[d/l]
[select]
Re^3: Split process->check ->and run Parallel
by roboticus (Chancellor) on Dec 24, 2008 at 14:16 UTC
    matrixmadhan:

    You're absolutely correct. But I wasn't trying to give him/her a complete solution--I wanted to give some hints. That's why I mentioned that the OP should look for various error conditions and solve them. After all, we've gotta leave some work for the OP!

    ...roboticus
[reply]
      But I wasn't trying to give him/her a complete solution--I wanted to give some hints.
      Perfect and agreed. Makes sense


      That's why I mentioned that the OP should look for various error conditions and solve them.
      Ok. I read your post again.


      After all, we've gotta leave some work for the OP!
      :)
[reply]

In Section Seekers of Perl Wisdom