Forum OpenACS Development: Re: About code executed in a new thread

Collapse
2: Re: About code executed in a new thread (response to 1)
Posted by Dave Bauer on 03/20/08 12:40 PM
use ns_eval {source /the/path}

This will reload in scheduled proc threads at least. I am not sure about ns_thread since I have never used it. I use the developer support shell to do this all the time. It also allows you to reload code when you are using performance mode and the standard reload mechanism does not run.

Collapse
3: Re: Res: Re: About code executed in a new thread (response to 2)
Posted by Raúl Morales Hidalgo on 03/20/08 01:03 PM
"It also allows you to reload code when you are using performance mode and the standard reload mechanism does not run"

I'm really interested in this as we are relying in our daily reboot to get the changes in in our production server.

So if I want to reload request-procesor-procs.tcl I just have to run in ds

ns_eval {source /path-of-our-source/packages/acs-tcl/tcl/request-procesor-procs.tcl }

Would it be possible to change apm reload behaviour to match this when performance_p is activated?

Thanks in advance

Collapse
6: Re: Res: Re: About code executed in a new thread (response to 2)
Posted by Luis de la Fuente on 03/20/08 01:40 PM
Thank you so much Dave, it works better now.

Another related question, about ns_thread and ad_schedule_proc

I am building a command in a variable to execute it later in a new thread. If I use ns_thread, it works. However I cannot make it work when using ad_schedule_proc with parameters.

Let's see a piece of code:
-------------
#build the command name
set command_name "imsld::gsi::${plugin}::check_requisites -petition_id $petition_id"

#reloads all the process in the file, even in threads
ns_eval {source /path/to/file.tcl}

#this line works, with ns_thread
ns_thread begindetached $command_name

#this line throws an error
ad_schedule_proc -thread t -once t 0 $command_name
##The error is:
##invalid command name imsld::gsi::clk::check_requisites -petition_id 1"
-------------

However, If I build 'command_name' without parameters, both methods work fine.

Why I am failing with ad_schedule_proc?

Luis

Collapse
8: Re: Res: Re: Res: Re: About code executed in a new thread (response to 6)
Posted by Raúl Morales Hidalgo on 03/20/08 01:48 PM
Luis,

Have you tried to separate command and args?

set command_name "imsld::gsi::${plugin}::check_requisite"
set command_args "-petition_id $petition_id"

ant then

ad_schedule_proc -thread t -once t 0 $command_name $command_args

Collapse
9: Re: About code executed in a new thread (response to 8)
Posted by Luis de la Fuente on 03/20/08 02:06 PM
Yes, I tried, but then the result was:

Invalid switch: "-petition_id 1"

Thank you anyway.

By now, I am using ns_thread, but I am curious about why I cannot use the scheduler...

Collapse
10: Re: Res: Re: About code executed in a new thread (response to 9)
Posted by Jose Pablo Escobedo Del Cid on 03/20/08 03:00 PM
Hi Luis!

Try this:


ad_proc -public test::test {param} {
.... (note the positional parameter)
}

set command_name "test::test"
set command_args 5 # use a list if you want more parameters

ad_schedule_proc -thread t -once t 0 $command_name $command_args

Collapse
11: Re: About code executed in a new thread (response to 10)
Posted by Luis de la Fuente on 03/20/08 03:17 PM
Thank you very much for the tip. It really helped!

Cheers,
Luis