[ntp:hackers] Patches to reinstate rank variable and add end
keyword.
Brian Utterback
Brian.Utterback at Sun.COM
Sun Aug 7 00:17:59 UTC 2005
I thought that was what you meant. The restriction on accessing multiple
cpus is within a single process. So, if you only want to use a single
cpu at a time, (i.e., not use threads within the process) everything is
fine. It all compiles just the same.
David L. Mills wrote:
> Paul,
>
> I'm apparently not asking the right question. I can access a 16-CPU
> Alpha. Can I compile and run ntpd on it? I can access a 2-processor Xeon
> running Windows. Same question. I can access a Solaris 10 with a bunch
> of processes (but not ntpd) pthreading. Same question.
>
> Dave
>
> Paul Vixie wrote:
>
>> dave, you wrote:
>>
>> # I have this little red flag waving in front of me. I hear good
>> things about
>> # bind 9. I would assume folks will gravitate to that for exactly the
>> reasons
>> # you cite - multiple CPUs and threads. If taskmgr is available and
>> works,
>> # why not use it?
>>
>> because a programmer who wants to write to the taskmgr API has to pay an
>> enduring penalty to get thread-safety. eventlib is much easier to write
>> an application around than taskmgr. since BIND9 includes a copy of both
>> libraries, for compatibility, and since freebsd includes eventlib in its
>> "libc", there's a growing likelihood that "eventlib" will already be
>> present on a system that wants to compile ntpd. or, if ntpd wanted to
>> include a copy of the library in order to be absolutely certain of its
>> availability, "eventlib" is quite a lot smaller than "taskmgr".
>>
>> # I take it taskmgr is restricted to bind 9 and eventlib is generic?
>>
>> not exactly.
>>
>> eventlib was written for bind8, and taskmgr was written for bind9. both
>> of them have been used by other apps than "named", but eventlib is older,
>> more widely known and more likely to be available.
>>
>> # Are multiple-CPUs and threads an inherent limitation of eventlib?
>>
>> yes. due to my ignorance when i designed the eventlib API, it's pretty
>> much
>> not possible to use eventlib and pthreads at the same time. on the
>> other hand
>> taskmgr was written with pthreads in mind, and as such, depends on
>> pthreads
>> even on uniprocessors if you want asynchrony. so listen carefully to this
>> next part: if you're considering taskmgr, you should just use posix
>> threads,
>> unless (like bind9) you're going to have hundreds of thousands of I/O
>> tasks
>> suspended pending network input, and hundreds of thousands of timers
>> waiting.
>>
>> # There are lots of places now running multiple CPU systems and
>> threads. We
>> # have a bunch of both here in department labs right now. I have used
>> # multiple-CPU Alpha in testing myself.
>> #
>> # I'm thrilled at putting everything under one blanket and especially
>> mowing
>> # lots of weeds. The above is of some concern.
>>
>> your choice is not between taskmgr and eventlib, it's between pthreads
>> and
>> eventlib. since i see no need for ntpd to be able to use multiple CPU's,
>> and since pthreads are far less portable than eventlib (think: sunos
>> 4.1.4
>> or ultrix), the right thing to use is eventlib.
>>
>> (if i were writing a non-threaded application from scratch today, that
>> needed
>> asynchrony, i would use eventlib. even in 2005. perhaps still in 2010.)
>>
>> paul
>
>
>
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers
More information about the hackers
mailing list