[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