On 2/10/07, Stephen Deasey <[EMAIL PROTECTED]> wrote:
On 2/10/07, Michael A. Cleverly <[EMAIL PROTECTED]> wrote:
> My adventures (with CVS HEAD) on OpenBSD/sparc64 continue.
>
> Unless I set:
>
> ns_section "ns/server/${servername}/module/nssock"
> ns_param acceptsize 1
>
> in my conf file then incoming an HTTP request never get serviced
> promptly; I can't connect to the nscp control port, and I can't hit
> CTRL-C to end the (foreground) nsd process.
The control port uses the nsd/sockcallback.c mechanism to handle new
connections, which runs in a seperate thread. So even if the driver
thread was blocked, I would not expect that to prevent you from
logging in via the control port.
What threading library does OpenBSD have these days? I thought they
had an option for real, 1-1 user-kernel threads.
Maybe we need to link to the correct thread library?
Still, the driver thread shouldn't be blocking...
You could try compiling the kernel with support for RTHREADS enabled.
Then compile the rthreads library in /usr/src/lib/librthread
Then link against it for 1-1 user-kernel threads.
Naviserver user threads sometimes explicitly to avoid blocking other
threads. With a user-level thread library any blocking thread will
block the whole process, so the extra threads will just be overhead.
A plain old single process server might perform better. (or multiprocess apache)