in reply to strange behaviour, would appreciate any comment / alternative method

I don't have an answer to your main question (yet), but I can tell you that this:

    my $t = scalar (@temp);
    splice (@temp,$t-1,1) if ($t );
    @jobstack=@temp;

[download]

Is a really slow, clumsy and silly way of doing this:

pop @jobstack.

[download]

which is exactly equivalent and about 100 times faster (depending upon how mush data is in @jobstack.

But the way you are using @jobstack suggests that you really ought to be using a Thread::Queue.

Whether that would have any influence upon your main problem I don;t have the facilities to test, but it would definitely make it easier to reason about the possible causes by eliminating one possible source of errors.

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.

Replies are listed 'Best First'.
Re^2: strange behaviour, would appreciate any comment / alternative method
by djamu (Initiate) on Jul 27, 2011 at 03:07 UTC
    Thanks for your prompt reply about using splice, I know it's a silly pop replacement, but as mentioned in the added comment I later need splice to arbitrarily remove items out of the array not push or pop.
[reply]
      I later need splice to arbitrarily remove items out of the array

      Hm. Three thoughts:

      1. Do it (that expensive clumsy copy-splice-copy operation) only when you need to.. Not when you only need to push/pop/shift/unshift.
      2. Copying a whole shared array to a non-shared array and then back again just so you can use splice is ... not good design.
      3. Removing elements from the middle of a structure called: @jobstack smacks of bad design or bad nomenclature.

      I rarely ever find myself needing to use splice. When I do find myself reaching for it, I always pause and look again at my design. 8 times out of 10 I find a better way.

      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]
        Ok, thanks for the advice on splice, didn't know it was that expensive.
        On the other hand the routine is rarely called and I have no control over what users submit / priority some jobs have ( the files itself contain that info ),
        and so the parser decides what file gets processed / computed
        ( these are long running job descriptions > +1 hour / job / CPU / compute node)
        I just mean to say that this snippet will only process a couple of files / hour ( not thousands / minute )

        I tested the Thread::Queue module and I'll keep it in mind as future reference, as I don't see a real use for it right now in the current code, (both the main / thread needs access to the same array > preventing jobs from getting processed multiple times )
[reply]
Re^2: strange behaviour, would appreciate any comment / alternative method
by djamu (Initiate) on Jul 27, 2011 at 03:16 UTC
    thanks for your suggestion on Thread::Queue .. that might solve some other difficulties I was having on shared arrays, I'll test it and post the result ()
[reply]
Re^2: strange behaviour, would appreciate any comment / alternative method
by Anonymous Monk on Jul 27, 2011 at 04:29 UTC
    Hi,

    I used to have problems with picking up incomplete files.

    Now I always have the file loaded in with a temp extentension, and then have the down/uploader rename it. Renaming is usually fast.

    I only look for files with the renamed extension.

    J.C.

[reply]

In Section Seekers of Perl Wisdom