in reply to Re: Re: Data copied with fork() -> how to access true data?
in thread Data copied with fork() -> how to access true data?

That's probably a good move anyway, though if there is any chance that you could upgrade your OS to something less than 10 years old, that would probably help your cause enormously also :)

With respect to rewriting your perl code, probably not.

For the most part, anything that runs on 5.6.1 should run on 5.8.x with minimal changes. That's a risky generalisation to make without having seen the code in question, but based on my own usage of both, it's not too wild a guess. Of course, my memory could be playing tricks on me again.

The harder question is how much effort will be required to make your current single threaded code run multi-threaded. On that, I will not even hazard a guess.

From the little information I have, your app is basically a big loop that get user input, uses it to modify the state of the current player, takes the opportunity to update the state of your NPC's and loops back for input.

Your desire is for the NPC's to run independantly of the user input. In theory, sharing the variables that contain their state with a background thread that loops over a sleep and modifies their behaviour is pretty trivial, but the devil is in the detail.

If your NPC's are OO-modelled, or if their state is maintained in nested hashes, or any number of other standard perl techniques, then the modifications could be awkward.

It may make more sense to simple use a timeout on your user input (using Term::ReadKey or similar), and just allow the NPC's to continue their state changes whilst the user thinks about his input.

How much effort would be involved, and whether multithreading would be beneficial relative to the other options available, will depend highly upon how your code is currently structured and how you want to modify it.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
  • Comment on Re: Re: Re: Data copied with fork() -> how to access true data?

Replies are listed 'Best First'.
Re: Re: Re: Re: Data copied with fork() -> how to access true data?
by muba (Priest) on Jun 01, 2004 at 19:50 UTC
    Yes, the NPC's are OO-modelled and their state is indeed maintained in nested hashes (if that means the $dude->{hitpoints} thing). Altough the Object Model will have to be revised (don't know if you care, but whatever)

    The current system indeed gets user input, executes the user command, lets the NPC do their moves (some kind of AS - Artifial Stupidity - they're not quite intelligent yet :) ) and then gets user input again. Term::ReadKey seems to be an attractive solution, thanks for the hint. But that also seems not to work on Windows systems. That is, it never worked for me.

    But I'll have a look at it!

    You say it'll depend on how my code is currently structured, but that's no important issue. Some procedures that should/could be part of the Classes, are still stored in the main part of the code (non-OO style), while others are stored in the class files. Some procedures that should be a method of class X that inherets from class Y, are stored in the file of class Y. So the current structure is Bad and really needs to be revised, as stated before.
[reply]
      But that also seems not to work on Windows systems. That is, it never worked for me. But that also seems not to work on Windows systems. That is, it never worked for me.

      Again, my best guess is that the reason it doesn't work for you is because you are using '98. It works for me on NT & XP.

      You say it'll depend on how my code is currently structured, but that's no important issue.

      Why it is important is that you cannot call objects across threads using Perl's iThreads implementation. You can share data, but not code pointers, ie. methods. That makes utilising objects with threads awkward.

      You could use a thread to interact with the user and queue the input to the main thread that manipulates the objects. That is pretty easy to do, but actually only achieves the same as putting a timeout on the IO, hence teh mention of ReadKey().

      If you thought is to make each NPC a separate thread running around on it's own and interacting when they come into contact, the problem is need to share the environment between threads. If the environment is also represented using objects, the problem of sharing those objects between threads returns.

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
[reply]
        Data sharing
        Yeah, I've had a look at the documentation. I also saw blessed hashes may be blessed in one thread but not in another. So I have to have a closer look at that.

        Main threat that communicates with the objects
        Your idea of the main threat maintaining the objects might be a good idea and I will consider it the most likely to use possibility for the moment.

        One thread per NPC?
        No, I was not intending to give every NPC its own thread. Actually, I only need two threads: one to take care of all NPC's (all NPC's are allowed to do their things one by one, maybe in a random order, maybe in order-of-appearance in the "realm"), one to take care of the human (well... let's hope so :D ) player.

        thinking aloud mode
        While philosophing a little about that, it might be a good idea to create a new thread whenever a new NPC has to be spawned. Then, within that thread, the first thing to do is to create a new instance of the appropriate class. But philosophing a little more, I come to the conclusion this will give problems when different objects need to get each other's data. This maybe might be solved by having subroutines in the main module that can access objects data. Although I do not quite see how to do this, it is worth to keep in mind, somewhere.

        For now... thank you!
        Good, it's late over here already and I am getting too tired to think straight, so I'll continue tomorrow. I've been playing around a little with programming different threads and I master the basics of it, so that part will not be too difficult.

        So far, thank you all for all the hints, help and links to documentation you gave me!
[reply]

In Section Seekers of Perl Wisdom