Forum OpenACS Q&A: anybody using [ns_thread begindetached]?

Collapse
1: anybody using [ns_thread begindetached]?
Posted by russ m on 07/01/03 06:37 AM

I've got a situation that looks like a perfect candidate for ns_thread begindetached, but as far as I can see it's non-functional in nsd built from aolserver3.3ad13-oacs1-beta-src.tar.gz

ns_thread begin works fine, but having to wait around to reap the threads defeats the purpose of using them in this case. ns_thread begindetached executes without error, but the specified function never gets executed...

I've grepped over 4.6 (which we're still using) and there are only 2 calls to ns_thread, both in the chat package - I haven't gotten around to checking whether the functionality they implement actually works...

Is anybody actually using ns_thread begindetached on nsd 3.3ad13?

Collapse
2: Re: anybody using [ns_thread begindetached]? (response to 1)
Posted by Andrew Piskorski on 07/01/03 08:22 AM
Yes, I use "ns_thread begindetached" regularly in AOLserver 3.3+ad13, although not often with OpenACS (which should make no difference). It works just fine, I believe exactly as documented. It definitely is doing something different from just "ns_thread begin", although FYI there was a bug in AOLserver 4 (fixed now I think) where "begindetached" was actually just doing the same thing as "begin".

I'm not using aolserver3.3ad13-oacs1-beta-src.tar.gz, I'm using the original 3.3+ad13 sources from aD, plus probably certain patches (I'd have to look). This is on Solaris.

FYI, when using plain "ns_thread begin" you don't have to wait for the thread to exit. Actually, I don't think I've ever tried it but I don't think anything bad will happen if you let the thread exit on its own without waiting for it. AFAIK the only difference between "begin" and "begindetached" is: With begin, you can wait for the thread to exit, and each such thread will count towards your configured maxthread number until it dies. With begindetached, you cannot wait for the thread to exit, and it does not count towards maxthread at all.

Collapse
3: Re: anybody using [ns_thread begindetached]? (response to 1)
Posted by russ m on 07/02/03 02:05 AM

I'm using solaris myself, and have seen this on both sparc and ia32 machines...

my understanding of the difference between begin and begindetached is that all threads count towards the configured maxthread limit, but begindetached threads are automatically reaped while begin threads need to be explicitly waited for...

I guess some experimentation is called for...

Collapse
4: Re: anybody using [ns_thread begindetached]? (response to 1)
Posted by Andrew Piskorski on 07/02/03 07:39 AM
Yes, I was at least partially mis-remembering what the ns_thread docs say. According to those you do need to call "ns_thread wait" on non-detached threads. Whether a detached thread counts toward the configured maxthread limit or not is unspecified in the docs. Should be easy to test empirically, I never needed to though.

What do you mean ns_thread begindetached is "non-functional"? What does it do? You should explain the problem fully, and then ask on the AOLserver list if necessary.

Collapse
5: Re: I suck (response to 1)
Posted by russ m on 07/02/03 08:12 AM

hmmm... let's just put it down to "pilot error"...

what I was seeing (and can no longer replicate :) ) was that ns_thread begindetached would be called and return without error, exactly as I expected it to, and nothing untoward would show up in the server error log, but the script specified for the new thread to run would not be run...

what I'm seeing now is that ns_thread begin and ns_thread begindetached both work fine, but will not see procs that were defined after server startup through OACS's file watching feature... and that I can live with...

Collapse
6: Re: anybody using [ns_thread begindetached]? (response to 1)
Posted by Andrew Piskorski on 07/02/03 08:46 AM
Yup, that sounds normal. I don't remember what magic the OpenACS APM file watching stuff uses exactly, but it never did work for new non-connection threads you explicitly spawn. It may not even work for the AOLserver scheduler thread, I don't remember.

Clearly the master thread that gets created at AOLserver startup is not modified by the APM stuff, and whatever hooks the APM has inserted to re-source the modified file into each new connection thread as it starts up are not taking effect for new non-connection threads.

That's how I remember it happening back when I last looked into it anyway, way back in ACS 4.2 days I think...