Returning to the caller of sceKernelLoadExec ?
-
- Posts: 37
- Joined: Wed Sep 07, 2005 3:41 am
- Contact:
Returning to the caller of sceKernelLoadExec ?
Is there a way to do so ?
sceKernelLoadExec reboots the PSP and loads up the executable you tell it to.
All other programs are thus no longer in memory...
You need to use sceKernelLoadModule and sceKernelStartModule. They work -very- well for this purpose, much faster too, however you have to worry about memory leaks and cleanup much more... and unfortunately you cant load elfs using this method... however you can compile your programs into prxs, and it'll work.
All other programs are thus no longer in memory...
You need to use sceKernelLoadModule and sceKernelStartModule. They work -very- well for this purpose, much faster too, however you have to worry about memory leaks and cleanup much more... and unfortunately you cant load elfs using this method... however you can compile your programs into prxs, and it'll work.
-
- Posts: 37
- Joined: Wed Sep 07, 2005 3:41 am
- Contact:
-
- Posts: 37
- Joined: Wed Sep 07, 2005 3:41 am
- Contact:
No, unfortunately it doesnt.
The way memory is allocated on the PSP is in memory partitions. Each of these partitions is created and doesnt seem to be tied to a thread or process or module.
When you create a memory partition (aka you call 'new' or 'malloc' which creates some large partition which your call is ACTUALLY allocated from) and dont free it, it just sits around taking up memory. When your application ends, this memory is freed as long as the 'destructor' gets called on your main function. Personally though, I dont like this approach and would rather have more control over it, but the sceKernelCreateFpl (creates a fixed length memory pool) functions havnt been put into the PSPSDK yet... Hopefully soon.
Unloading a module only removes the small memory partition that was created to store the actual module itself in memory. It doesnt even free the memory used to hold the threads (500KB per thread or so)!!! Even letting your threads just quit doesnt end them, you MUST call sceKernelExitThread or whatever its called. Its pretty craptastic. :) This is one of the reasons most games on PSP dont use multiple modules.
The way memory is allocated on the PSP is in memory partitions. Each of these partitions is created and doesnt seem to be tied to a thread or process or module.
When you create a memory partition (aka you call 'new' or 'malloc' which creates some large partition which your call is ACTUALLY allocated from) and dont free it, it just sits around taking up memory. When your application ends, this memory is freed as long as the 'destructor' gets called on your main function. Personally though, I dont like this approach and would rather have more control over it, but the sceKernelCreateFpl (creates a fixed length memory pool) functions havnt been put into the PSPSDK yet... Hopefully soon.
Unloading a module only removes the small memory partition that was created to store the actual module itself in memory. It doesnt even free the memory used to hold the threads (500KB per thread or so)!!! Even letting your threads just quit doesnt end them, you MUST call sceKernelExitThread or whatever its called. Its pretty craptastic. :) This is one of the reasons most games on PSP dont use multiple modules.