From what I see, there are several choices:


Adding SIGTHREAD, SIGTHREADV, and two itimers just for threads:

Pros:

	Since only the NetBSD supplied threading code will use it, we
	can kill the interface into the kernel fairly easily.

	It won't take long to implement.

	We get a working pthread implementation with minimal hair.

Cons:

	It requires a non-standard interface into the kernel that we
	must keep around at least one OS release after the one that
	introduces it.


Adding a general purpose timer allocation method (allocitimer, then
sigaction and setitimer):

Pros:

	I have it mostly written.  :)

	Non-system supplied code will use the interface, which we will
	be killing eventually.

	We get a working pthread implementation with minimal hair, and
	other applications can benefit.

	We apparently get a checkpointing package, too.

Cons:

	Once again, non-standard interfaces will be a short-term pain
	for us.

	Since others will use it, come third-party code will break
	when the interface vanishes.


Posix sigevent et. al. support:

Pros:

	Follows a standard.

	Pthreads and other non-system-supplied code can use it and not
	worry about changes later.

Cons:

	I don't have the time/knowledge to code such a thing.  This
	will delay adding libpthread as a standard library.  I believe
	this will hurt us in the short and long term, since bind9 will
	need pthreads, and many other packages are coming out with
	thread support.

I'd like to go with #2, and splat on every man page that the interface
is temporary, and it _will_ go away in a future release.  I personally
need threads _now_  -- without them, I may have to install FreeBSD
just so I can do work on bind9 without fighting with the OS.  And I
think that would really suck.

--Michael