Re: [wessels@squid-cache.org: cvs commit: squid configure.in configure]

 I've commented on this already before, and I'm not sure which way
 is right to go. I fixed the issue for myself by:

Index: aiops.c
===================================================================
RCS file: /cvsroot/squid/squid/src/fs/aufs/aiops.c,v
retrieving revision 1.3
diff -u -r1.3 aiops.c
--- aiops.c 2000/11/11 09:40:02 1.3
+++ aiops.c 2000/12/04 15:22:32
@@ -800,7 +803,11 @@
     }
     /* Give up the CPU to allow the threads to do their work */
     if (done_queue.head || request_queue.head)
+#ifndef _SQUID_SOLARIS_
        sched_yield();
+#else
+ yield();
+#endif
 }
 
 aio_result_t *

 I tend to think that we shouldn't add libs to squid unless really
 needed. librt defines lots of stuff, including, on solaris, aio_read,
 aio_write and other aio_* calls that clash with current squid naming.

 I think that sched_yield(); is not part of posix threads and could
 cause problems on other OSes as well.
 As its only task is to give up CPU at this only point, I think it
 would be more appropriate to use something that is available with
 current libs. I can't speak of other OS'es, but Solaris has options
 to use thr_yield() (which is defined with posix threads also) and
 yield(), which should be most portable. As I understand it, yield()
 is wrapped when linking with threads, with appropriate call to
 give up CPU for a running lightweight process. So, most probably
 it would be wrapped into thr_yield() on Solaris.

 I can't think of any reason why we need to call sched_yield(), if
 someone can comment on this, why this call was used instead of
 plain old yield(), there would be more to think about.

 I personally don't think it is a good idea to link RT into squid,
 it might wrap lots of stuff to provide realtime extensions, thus
 adding to overhead. We don't need or use it.

 Finally, I'm not sure if its a good idea to forcibly give up cpu
 at all. This isn't quite clean MT programming. One thread shouln't
 care about how or when others are running. If it has nothing to
 do, it should sleep on either syscall or mutex. Most often trying
 to give up cpu gives nothing, but adds to overhead. For eg. Solaris
 would most probably return immediately if lwp's timequantum has
 not expired, thus being nop with quite some overhead. on a MP
 system this call has not much sense, because another thread might
 be well ready to run on another cpu. thread syncronisation should
 be done differently.

 my 0.02c

On 1 Dec 2000, at 15:57, Adrian Chadd <adrian@creative.net.au> wrote:

> Ok,
>
> Can solaris people (andres?) check this out? Duane beat me .. :)
>
> ----- Forwarded message from wessels@squid-cache.org -----
>
> wessels 2000/11/30 17:02:57 MST
>
> Modified files:
> . configure.in configure
> Log:
> Chris.Tilbury@warwick.ac.uk says we need -lrt on Solaris now to compile
> async I/O.
>
> Revision Changes Path
> 1.207 +3 -0 squid/configure.in
> 1.209 +88 -52 squid/configure
>
>
> ----- End forwarded message -----

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Mon Dec 04 2000 - 08:47:24 MST