forums.ps2dev.org

[Torch]

How do I call a 'delegate' function in the PSPSDK?
Basically I am using a class in my main thread, and I launch one of its functions as a new thread. Now from the new thread how do I call a member function but have it run in the context of the main-thread.

Right now I'm using a crude method of setting up some global variables, and continuously checking the variables from the main thread, if a variable is set (by the new thread) the corresponding function is called in the main thread.

[jean]

The word delegate has been introduced by microsoft with their C# to mean a function pointer in a managed environment. If i understand, what you are basically asking is how to replicate the obj.Invoke(fnDelegate); to make a thread call a function in its context from another thread. This is not very simple and definitely not straightforward - if there's not a dedcated function that i don't know. A possible way is to pass the function pointer writing in a shared memory location and then unlock a semaphore. At least that's the way used in other c/c++ cross-platform projects.

[Torch]

The semaphore method is basically the same as my global variable stuff. I don't need to go as far as a function pointer because I only need 2 or 3 specific functions which the main thread can decide depending on the value of the variable. However this will cause a delay depending on how often the main thread loops and checks the semaphore (if its a blocking wait then its more or less instant) but I want my main thread to do other processing as well instead of just blocking until the semaphore is unlocked. Since my main thread has a delay of 100000 it will take a short while before the function call occurs.

My specific problem is that I need to call some ordinary sce* functions from inside a syscon_debug_handler. However this is obviously not to be done as it blocks all syscon packets till the function returns and will cause very strange side effects, including hardware malfunction. Hence I'm setting a global from inside the syscon handler and that is being checked by the main thread whether to execute a function. The only problem here is the slight delay caused by the main loop's delaythread function as I don't want it hogging CPU.

[moonlight]

Not totally sure, but maybe threadman callbacks can resolve your problem.
You create the callback in a thread A, and then it can be notified from other thread B with sceKernelNotifyCallback, the function will be executed on context of thread A. However, thread A should be checking for callbacks using sceKernelCheckCallback or having entered in a a sleep/delay/wait state with one of the CB versions of those wait functions.

[Torch]

Just tried it. In the main thread I used sceKernelDelayThreadCB for delaying.
The function is executing instantly (because the main thread is in DelayCB for most of the time anyway, the remaining code is small).

But when I call sceKernelNotifyCallback from inside a syscon debug handler, it again causes hardware malfunction. (Almost all sce* functions cause problems). Some times it shows no battery icon and shuts down, or it shows external power source, or screen starts flickering etc. (When such problem occurs it doesnt even go away with kernel reboot, or soft reset. Only cold boot will fix it.)

Only "normal" code without any external calls seems to work inside syscon debug handler.

[TyRaNiD]

I would ask what on earth you are doing, but then I realised you have no idea what you are doing so I can't be bothered to give you a sensible answer :)

[Torch]

[Torch]

Inside this function...

[ctszy]

not sure though.. but seems Booster has done sth similar with yours?
just Google "vshex_syscon" and take a look :)

[Torch]

[TyRaNiD]

Unfortunately really the best you can have is sceKernelNotifyCallback as it is able to be called in an interrupt context (which I assume this is). If that is still screwing things up, well it is difficult :) You could try EventFlags but not sure that is going to significantly help you.

[Torch]

[ne0h]

I'm not totally sure but EventFlags is like global variabiles, there's no way to send a "immediate request" to another thread, there's sceKernelPollEventFlag or sceKernelWaitEventFlag, but is the same thing as:

[Torch]

Event flags has a wait timeout, so I guess its effectively the same as DelayThreadCB. If the event occurs while its waiting it will fire, other wise it goes to the next iteration and executes my other code first before waiting again.

I haven't tried it in my plugin yet to see if it screws up.

[Torch]

@TyRaNiD

I noticed you didn't read my PM. I assumed you read it first yesterday and then replied here about the EventFlags. It contains the source code of my plugin, so if you take a look at that it might help with some ideas.

[Jim]

Is it not possible to have a high priority thread waiting on a semaphore. In your debug thread you raise the semaphore and yield. That should make the high priority thread run immediately.

Jim
_________________
http://www.dbfinteractive.com

[Torch]

I can't call the sema functions from the debug thread, it also malfunctions.

I'm yet to try the EventFlags, I'm away from my dev pc at the moment.

[Torch]

I wasn't able to get event flags working properly.

Is there anything special I have to do while using sceKernelNotifyCallback from an interrupt context? Sometimes it works, but during some games (specifically God of War) it causes an instant crash (full power off, no led, no display, and an audible pop from the speakers).