[Lcdproc] lis driver fails to compile

[Daryl F]

Ah, I was just an innocent babe in the woods. Then out from behind a
tree jumped the _Threads_Wolf_. After reading about threading and it's
evolution in Un*x variants, esp. http://www.kegel.com/c10k.html it
seems that I can't have just one implementation for all.
 
If libpthread is used it seems it will eventually be obsolete in Linux
because of the progress on NPTL. And if I use NPTL only, it is
unclear when, or if, FreeBSD will support it.

That leaves the less-desirable alternative, conditional code in
lis.c to use one or the other, preferring clone() but using
pthread_create() if clone() is not available in libc. It complicates
testing a bit but it should work.

I've modified configure.in to test for clone() and failing that to
check for pthread_create() and generate preprocesor variables
accordingly. And I've added the code Rene Wagner suggested to lis.c for
libpthread with #if. I can compile the lis driver now with either one of
the two thread creation functions.

I've a few more steps to do before the patch is ready:
1) test both versions of the driver
2) add a test somewhere to disable building the lis driver if clone()
or pthread_create() is not available. I'm not sure if this is necessary
but am guessing the situation might arise.

Item #2 is necessary because the code currently won't create the thread
if neither clone() nor pthread_create() are available. The driver won't
work without the read being present at all times. And it can't simply
refuse to run if it can't create the thread as that would likely
generate a lot of questions to this list. It seems better to not create
the driver at all than wait until run-time to inform them it is not
possible because the system doesn't have either one of the thread
creations functions.

Does this seem like a reasonable solution? Or should I allow the driver
to compile and then produce an error when run if it is not possible to
create the thread?

Regards,
Daryl