Can someone suggest an optimal minimum stack size for a WIFI background thread I'm using in my application? I have it set to 4096 right now (I've seen this sized used elsewhere). I am not passing in any parameters to my thread.
>> Main thread in KERNEL mode
>> USER mode thread created for running most things
>> the other USER mode thread spawns a USER mode thread created for WIFI stuff in background
My program is working like this. Wav audio is a bit choppy when it first starts but I am still tweeking thread priorities.
From what I've gathered, any threads working with WIFI must be running in USER mode vs. Kernel mode -- correct? (just checking).
Thanks in advance.
David Beyer
wlan/threads
Yeah you need to connect to the wifi from a user mode thread to get it to work with DHCP iirc.
What does your wifi thread do? connect to wifi, create and use a tcp socket?
The stack size may be large enough, depends on what it's doing, I've basically set my stack sizes in peldet to numbers where peldet runs and doesn't crash because of them (how very scientific).
You want to do as few things in kernel mode as possible, really just load the required modules, set an exit callback and boot your user mode threads.
A few of functions don't work under kernel mode, or seem to do weird things if you try use them from both kernel mode and user mode.
I think I had trouble when I was trying to add in message boxes, I created them in a kernel mode thread and my user mode threads couldn't access them.
What does your wifi thread do? connect to wifi, create and use a tcp socket?
The stack size may be large enough, depends on what it's doing, I've basically set my stack sizes in peldet to numbers where peldet runs and doesn't crash because of them (how very scientific).
You want to do as few things in kernel mode as possible, really just load the required modules, set an exit callback and boot your user mode threads.
A few of functions don't work under kernel mode, or seem to do weird things if you try use them from both kernel mode and user mode.
I think I had trouble when I was trying to add in message boxes, I created them in a kernel mode thread and my user mode threads couldn't access them.
-
dbeyer3069
- Posts: 81
- Joined: Mon Dec 19, 2005 4:09 pm
Right now I'm just in the early stages of setting up a state machine to handle all the transmit/receive, establishing connections, breaking them down, etc. I don't want to have to create 50 different functions to handle everything... so I am coding it like other apps I've written (one side starts a process and the other handles the results). Mine isn't going to be a small app.What does your wifi thread do? connect to wifi, create and use a tcp socket?
The stack size may be large enough, depends on what it's doing, I've basically set my stack sizes in peldet to numbers where peldet runs and doesn't crash because of them (how very scientific).
It doesn't seem to make any difference if I spawn both user threads in the kernel main..or If I spawn the second user thread from the main user thread (just makes a difference which thread is the parent).You want to do as few things in kernel mode as possible, really just load the required modules, set an exit callback and boot your user mode threads.
A few of functions don't work under kernel mode, or seem to do weird things if you try use them from both kernel mode and user mode.
I think I had trouble when I was trying to add in message boxes, I created them in a kernel mode thread and my user mode threads couldn't access them.
Since I'm not passing a whole bunch of data onto the stack (I'm passing nothing right now), I'm assuming there isn't much need for stack space. The ? marks come in where I don't fully understand how the PSP uses the stack space vs. normal pc apps.
Thanks,
David Beyer
> Can someone suggest an optimal minimum stack size for a WIFI background thread I'm using in my application?
The "background" thread used by the WiFi stack is not normally allocated in your code (unless you are rolling your own startup). It is hard coded in the startup code (my "nlhInit" or the SDK "pspSdkInetInit")
It is passed as an argument to "sceNetInit" (IIRC the last one). The default 0x1000 should be enough (that's what most games use).
The size of your kernel mode or user mode stacks will depend on what you are doing. As mentioned it is best to call the main "sceNet" functions -- including the initialization call -- from a user mode thread (doesn't matter how it is created) for a number of reasons.
The "background" thread used by the WiFi stack is not normally allocated in your code (unless you are rolling your own startup). It is hard coded in the startup code (my "nlhInit" or the SDK "pspSdkInetInit")
It is passed as an argument to "sceNetInit" (IIRC the last one). The default 0x1000 should be enough (that's what most games use).
The size of your kernel mode or user mode stacks will depend on what you are doing. As mentioned it is best to call the main "sceNet" functions -- including the initialization call -- from a user mode thread (doesn't matter how it is created) for a number of reasons.
-
dbeyer3069
- Posts: 81
- Joined: Mon Dec 19, 2005 4:09 pm
The background thread I'm talking about is the one where I want WGET, transmit/receive, file transfers, etc. to actually take place (the thread). The init is called from my WIFI thread (user mode). Am I missing something and making this more complicated? You are saying that the startup code creates a thread on its own suitable for running my code..and then calls my function (a callback?).PspPet wrote:> Can someone suggest an optimal minimum stack size for a WIFI background thread I'm using in my application?
The "background" thread used by the WiFi stack is not normally allocated in your code (unless you are rolling your own startup). It is hard coded in the startup code (my "nlhInit" or the SDK "pspSdkInetInit")
It is passed as an argument to "sceNetInit" (IIRC the last one). The default 0x1000 should be enough (that's what most games use).
The size of your kernel mode or user mode stacks will depend on what you are doing. As mentioned it is best to call the main "sceNet" functions -- including the initialization call -- from a user mode thread (doesn't matter how it is created) for a number of reasons.
David Beyer