Forum OpenACS Development: About code executed in a new thread

Hello,

I need to work with threads working in background, so I am using 'ns_thread' and/or 'ad_schedule_proc' (I have not decided which one yet). When using them, I find the following behaviour:

The code executed by the new thread is the existing code when the server started up, no matter if I've made changes on the procedure.

However, if I call the same code directly (without threads), the code is correctly updated whenever I make changes on it. Of course, the server is watching the corresponding files.

So the question is: Is there anyway to re-register the process and execute the updated code in the thread? (Restarting the server on every test is so boring...)

Thanks in advance
Luis

Collapse
Posted by Dave Bauer on
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
Posted by Raúl Morales Hidalgo on
"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
Posted by Luis de la Fuente on
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

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
Posted by Luis de la Fuente on
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...

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
Posted by Luis de la Fuente on
Thank you very much for the tip. It really helped!

Cheers,
Luis

Collapse
Posted by Dave Bauer on
Yes, in fact it makes more sense to just reload using ns_eval all the time.

We still would need to handle XQL changes, but since the XQL is shared across threads (I think, I really need to check again) just calling dq_qd_load_query file directly will reload the xql.

I had some experimental code for this, but I might have misplaced it when I reinstalled everything on my computer.

I am willing to work on this to get this feature into the next version of OpenACS.

Collapse
Posted by Don Baccus on
Yes, in fact it makes more sense to just reload using ns_eval all the time.
The reason it doesn't is that ns_eval didn't exist when the apm reload facility was written, that came along later.

We've had this discussion once before, I swear, and someone had said they were going to implement it, and it didn't get done, and ...

https://openacs.org/forums/message-view?message_id=923672

Oh, look, it was Dave Bauer!

We never adopted that TIP hmm ... I've just checked, it's in 4.0.1, and I doubt if anyone but me uses any AOLserver that old or older (don't worry, it's only on my macbook pro, I had it laying around and you don't have to compile tcl with 64 bits to use it), so seems safe enough.

Maybe you'd like to resurrect that TIP and get it approved and put it in?

Collapse
Posted by Stefan Sobernig on
Luis,

You might want to consider xotcl-core and its threading helpers, defined in xotcl-core/tcl/40-thread-mod-procs.tcl. There are many nice aspects about these helpers (persistent vs. volatile threads), but, regarding your case, ordinary apm reloads are supported. Once the thread-declaring file is piped throught the apm reload mechanism, the ::xotcl::THREAD object takes care of re-initialising the managed Tcl thread (through the XOTcl recreation mechanism, for the interested reader). But the interface hides this from you, completely!

See api-doc for intro reading ...

cheers
//stefan

Collapse
Posted by Luis de la Fuente on
Thanks Stefan, I will take a look.