NTPL
NTPL
Есть вопрос: будут ли жить программы собраные для RH9 (с nptl) на ядре без nptl? И наооборот, будут ли жить программы собраные без nptl (debian) на ядре с nptl ?
Я хочу поставить на сервер параллельно с debain еще suse, RHEL/RHAS и Alt Linux (последний скорее изврата ради)
Существует ли для RH*, SUSE и Alt что-то типа base-system ? Т.е. некия тарбол с бинарями, или минимальный набор RPM который позволит после их установки получить рабочую систему???
Я хочу поставить на сервер параллельно с debain еще suse, RHEL/RHAS и Alt Linux (последний скорее изврата ради)
Существует ли для RH*, SUSE и Alt что-то типа base-system ? Т.е. некия тарбол с бинарями, или минимальный набор RPM который позволит после их установки получить рабочую систему???
Опыт растет прямо пропорционально выведенному из строя оборудованию
если собраны статически, то по-идее должны, если линковались против шареных либ, то 100% будет все окей. Дело в том, что либа всЁ та же, libpthreads.so (static .a я не юзал ), по-етому самой проге пофиг как сама либа была собрана.. главное название для dlopen() и точки входа функций для dlsym().. Короче, я сам тестил наш продукт (ну очень малти-thread-овый) не что что против ntpl, но даже против ngpt (New Generation POSIX Threading).. если какие траблы будут -- звони, или в асю..
gl
gl
Never touch the running program!!!
кстати на одной системе можно держать несколько pthreads либ (да и не только pthreads ).. для того чтоб узнать какая юзается прогой достаточно выполнить ldd на файл.. если надо чтоб взялась другая, а не текущая, тогда пропиши путь в LD_LIBRARY_PATH..
а вообще-то я не знаю прог, которые юзают особенности NTPL, кроме кенела ну и соответсвенно libc, так что малти-thread-овые проги должны работь, если нет то поставь либы в альтернативный директорий..
gl
а вообще-то я не знаю прог, которые юзают особенности NTPL, кроме кенела ну и соответсвенно libc, так что малти-thread-овые проги должны работь, если нет то поставь либы в альтернативный директорий..
gl
Never touch the running program!!!
а вообще changelog для glibc на RH9 показывает:
Код: Выделить всё
* Fri Feb 14 2003 Jakub Jelinek <jakub@redhat.com> 2.3.1-45
- update from CVS
- include also linuxthreads FLOATING_STACKS libs on i686 and athlon:
LD_ASSUME_KERNEL=2.2.5 to LD_ASSUME_KERNEL=2.4.0 is non-FLOATING_STACKS lt,
LD_ASSUME_KERNEL=2.4.1 to LD_ASSUME_KERNEL=2.4.19 is FLOATING_STACKS lt,
later is NPTL
- enable TLS on alpha/alphaev6
- add BuildPreReq: /usr/bin/readlink
Never touch the running program!!!
ну да правильно.. бывает! кстати NGPT -- ето Next Generation POSIX Threading .. http://www-124.ibm.com/developerworks/oss/pthreads/ самое главное отличие и от LT и от NPTL заключается в том, что тут уже реализована 'нормальная модель thread-ов', т.е. все thread-ы находятся реально в одном процессе... а не каждый в своем kernel-process как сейчас.. Единственно могу сказать, что пока ета либа еще сыровата.. для простеньких малти-thread-овых приложений работает ок, но для реальных приложений во время стресс-тестов просто виснет..Native Posix Threading Library. Так правильно.
Never touch the running program!!!
Aleksey Kondratenko, кстати все-таки правильно New а не Native
короче не суть важно!
см. http://www-124.ibm.com/developerworks/o ... nouncementAs many of you may know by now, a new POSIX threading library NPTL
(http://people.redhat.com/drepper/nptl-design.pdf) is now available for Linux
короче не суть важно!
Never touch the running program!!!