Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
23 crawler(s) on-line.
 67 guest(s) on-line.
 1 member(s) on-line.


 Templario

You are an anonymous user.
Register Now!
 Templario:  1 min ago
 NutsAboutAmiga:  7 mins ago
 RobertB:  12 mins ago
 Gunnar:  14 mins ago
 GPTNederlands:  28 mins ago
 janelancy:  29 mins ago
 -Sam-:  37 mins ago
 OlafS25:  1 hr 20 mins ago
 pixie:  1 hr 21 mins ago
 Rob:  1 hr 35 mins ago

/  Forum Index
   /  Amiga Development
      /  Could the Amiga multitasking system actually make fork() easier than we thought?
Register To Post

PosterThread
Hypex 
Could the Amiga multitasking system actually make fork() easier than we thought?
Posted on 27-Jun-2017 9:55:45
#1 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

I've been looking into the process that fork() performs on a common multitasking OS and wonder if it might be easier than we thought. Keeping in mind the old AmigaOS joke of Exec being a single task and Amiga processes being threads. I think this may help in our regard.

In standard practice a fork() will split a process into two, essentially creating a clone with its own address space. And a clone with one attribute, namely the copy-on-write protocol in place. I wonder if we can make use of this? Since Amiga memory is shared between processes.

Of course, if the child simply reads variables, then this system would work fine. But, an issue occurs when the child writes to a variable since then it needs its own copy. And this issue extends futher upstream when the parent process writes into its space that must be cloned in the children. Think of the children.

Normally this is solved through the use of virtual memory and programming the MMU to pick up on things like this. OS4 supports MMU programming so it's possible this could be done as it is normally.

Another thing is threads. OS4 still lacks threads. But I think the system design allows for threads to be created easily. If we think of a thread as simply a sub-task of a task where it just executes another block of code in the context of the parent process then adding thread support would be trivial at least.

Imagine a process is divided into threads in this case. There is a parent process. When that process kicks in, the entry point will run through a list of threads, and these will be executed in order until the quantum runs out. These threads are essentially like a parallel function in the code, when they execute their stack frame is restored, including IP and registers. The code is ran as usual. Until they implicitly Wait() or the quantum expires. The stack frame is then saved, including IP and registers. If the process still has quantum time left then it's onto the next thread. Otherwise time up.

With this system only one real process is needed. Since the thread code is ran like it would be in a standard process, except different sections of code are ran in order, each isolated by stack, registers and IP.

Expanding to a real fork() would be harder. Since in this case a seperate process would really need to be created. And here there is a major problem: cloning it. I see this as a problem because all the file handles, variables and other process data needs to be copied. Except through a thread safe C lib could files be cloned and even then there are file handles to take care of. But with native Amiga files this gets worse as you have a pointer into process memory as well as other handles in unknown locations and these need to be cloned. Aside from this there is cloning the stack frame, including IP and registers so the child can execute from the same point as if it just returned from the orginal location. So perhaps harder than thought.

I've been pondering my idea of threads for some years and if it would actually work. But I haven't done any experiments yet. Perhaps I should do some testting. We might just get a CreateThread().

Last edited by Hypex on 27-Jun-2017 at 10:13 AM.

 Status: Offline
Profile     Report this post  
Chain-Q 
Re: Could the Amiga multitasking system actually make fork() easier than we thought?
Posted on 27-Jun-2017 13:12:36
#2 ]
Cult Member
Joined: 31-Jan-2005
Posts: 824
From: Budapest, Hungary

@Hypex
Quote:
Of course, if the child simply reads variables, then this system would work fine. But, an issue occurs when the child writes to a variable since then it needs its own copy. And this issue extends futher upstream when the parent process writes into its space that must be cloned in the children.

So you want to create a per process address space in the middle of the shared address space? Right. Not to mention what happens when both "forks" start to allocate more memory, so you end up with a chain of fragmented "private" and "shared" memory blocks. Good luck finding an MMU and an algorithm which can support that with reasonable effort. And this is only the start of your problems. For example, what happens if I pass a pointer to an OS function, which is allocated in my stack or my virtualized address space heap. But I pass my *LOCAL* pointer in my *LOCAL* address space, which will be either my parent's address space or something completely different from the called OS functions viewpoint. Remember, we're dealing with massively parallel APIs here, like the device I/O system. Etc... TL;DR: fork() with the current Amiga memory model is impossible. Deal with it.

Quote:
Another thing is threads. OS4 still lacks threads. But I think the system design allows for threads to be created easily.

Yes, but - with minimal restrictions - the current shared memory model means AmigaOS processes are barely more than threads in another system. Therefore you can handle them like that. This property is what I used when I implemented threading support in Free Pascal across all Amiga systems.

But there are other implementations too, like I think all Amiga-like systems have a more-or-less working pthreads or C11 native threading implementation in some form, which uses the same principles. (For example OWB needs this anyway.)

This is not rocket science, and known for years. And it's not possible to extend this model to a fork() model, for the problems mentioned above.

_________________
MorphOS, classic Amiga, demoscene, and stuff
"When a bridge is not enough, build a Viaduct!"
"Strip the Amiga community of speculation and we can fit every forum on a 720k floppy" (by resle)

 Status: Offline
Profile     Report this post  
Hypex 
Re: Could the Amiga multitasking system actually make fork() easier than we thought?
Posted on 3-Jul-2017 7:57:11
#3 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@Chain-Q

Quote:
So you want to create a per process address space in the middle of the shared address space?


Actually I'd like to create a cloned process address space since the memory is already shared. And take advantage of that. A a per process address space is where we should be now.

Quote:
Not to mention what happens when both "forks" start to allocate more memory, so you end up with a chain of fragmented "private" and "shared" memory blocks.


The way it is now a process can have private and shared memory. As well as execute memory.

Quote:
Remember, we're dealing with massively parallel APIs here, like the device I/O system. Etc... TL;DR: fork() with the current Amiga memory model is impossible. Deal with it.


LOL. That's why I thought taking advantage of shared memory rather than trying to work against it may be a better solution. It also depends on how deep a fork() goes. There would be simple examples where it just forks so the main code is left resident and returns control back to the terminal. Which would be like detaching a shell process. Possible. There would be forking so the code is running in threads. Possible if simple. And more complicated examples making full use of forking. Bordering on impossible.

Quote:
Yes, but - with minimal restrictions - the current shared memory model means AmigaOS processes are barely more than threads in another system. Therefore you can handle them like that.


That's what I noticed too in current models including pthreads. The difference here is there is a separation. Because a different process is acting as a thread. I think this too introduces problems even with a shared memory model. Since any global variables, library bases and any other handles cannot be really shared. Only thing would be shared is data.

A thread model kept inside the current process would allow proper sharing of resources since it would remain in the same process context.

More likely than a fork model in any case. Though the fork model looks too deep to me by duplicating a task if only a threading is needed. And these days threading is in popular use.

 Status: Offline
Profile     Report this post  

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle