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
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:02 MST