# libxml bundling - Thread: https://externals.io/message/1323 - Original archive: https://news-web.php.net/php.internals/1323 - Started by Edin Kadribasic on 2003-05-06T22:17:51+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #1323 — Edin Kadribasic — 2003-05-06T22:17:51+00:00 URL: https://externals.io/message/1323#1323 Sterling, You have just added 3.5 MB of source into the PHP code tree despite your assurances that libxml was only "slightly" bigger than expat which takes up "only" 432 KB. This is IMHO completely unnecessary as libxml comes preinstalled as a shared library on most modern Unix systems and because it adds bloat to PHP distribution. In my opinion this bloat should be removed. Edin --- ## #1324 — Sascha Schumann — 2003-05-06T22:20:30+00:00 URL: https://externals.io/message/1323#1324 · In reply to: #1323 > In my opinion this bloat should be removed. Seconded. - Sascha --- ## #1325 — James Cox — 2003-05-06T22:25:40+00:00 URL: https://externals.io/message/1323#1325 · In reply to: #1323 > You have just added 3.5 MB of source into the PHP code tree despite your > assurances that libxml was only "slightly" bigger than expat which takes > up "only" 432 KB. > > This is IMHO completely unnecessary as libxml comes preinstalled as a > shared library on most modern Unix systems and because it adds bloat to > PHP distribution. > > In my opinion this bloat should be removed. No kidding. Sterling, what is wrong with linking to libxml that's more than likely going to be present, or if it's not found simply downloading and compiling libxml from a designated site? -- james --- ## #1327 — Jani Taskinen — 2003-05-06T23:39:30+00:00 URL: https://externals.io/message/1323#1327 · In reply to: #1323 >Sterling, > >You have just added 3.5 MB of source into the PHP code tree despite your >assurances that libxml was only "slightly" bigger than expat which takes >up "only" 432 KB. > >This is IMHO completely unnecessary as libxml comes preinstalled as a >shared library on most modern Unix systems and because it adds bloat to >PHP distribution. > >In my opinion this bloat should be removed. Me three. --Jani --- ## #1328 — Dan Kalowsky — 2003-05-07T00:33:37+00:00 URL: https://externals.io/message/1323#1328 · In reply to: #1323 Consider this a me fourthed message. This still is one of my biggest developer annoyances... bundling of extra software. > Sterling, > > You have just added 3.5 MB of source into the PHP code tree despite your > assurances that libxml was only "slightly" bigger than expat which takes > up "only" 432 KB. > > This is IMHO completely unnecessary as libxml comes preinstalled as a > shared library on most modern Unix systems and because it adds bloat to > PHP distribution. > > In my opinion this bloat should be removed. > > Edin > > > > >---------------------------------------------------------------< Dan Kalowsky "I'll walk a thousand miles just http://www.deadmime.org/~dank to slip this skin." dank-nom@aps-deadmime.org - "Streets of Philadelphia", kalowsky@php.net Bruce Springsteen --- ## #1329 — ed000001@hotmail.com — 2003-05-07T02:40:39+00:00 URL: https://externals.io/message/1323#1329 · In reply to: #1328 Dear folks, Forgive me for barging in, but I'm using a snippet of code that might be of interest. It is a "test and set" function to be used for locking resources across threads. I was looking at the TSRM implementation (including the Mutexes) and it did do quite what i needed -- things are not atomic. So here are a couple of primitives in VC++ (Windows) and gcc (Linux) for the i386 platform. The Linux piece was "stolen" from /usr/include/asm/bitops.h -- originally written by Linus Torvalds. I "ported" it to VC++. With these 2 inline primitives people developing extensions should be able to implement thread shared resources with safety -- provided one does not make mistakes ;-) They seem to work -- no guarantees though :-) There is an example of usage below, but one can come up a number of variations for the "wrappers" based on the "inlines". Thanks for the great tool! All the best, Ed Hoo ed000001@hotmail.com *** MY_FILE.H *** /* ------------------------------------------------------- *\ * Primitives for a simple mutex implementation * ------------------------------------------------------- */ #define ADDR (*(volatile long *) addr) #ifdef WIN32 static __forceinline int test_and_set(int nr, volatile void *addr) { __asm { mov eax, nr mov ebx, addr lock bts [ebx], eax sbb eax, eax } /* Return with result in EAX */ } static __forceinline int test_and_clear(int nr, volatile void *addr) { __asm { mov eax, nr mov ebx, addr lock btr [ebx], eax sbb eax, eax } /* Return with result in EAX */ } #else static __inline__ int test_and_set(int nr, volatile void *addr) { int oldbit; __asm__ __volatile__( "lock ; " "btsl %2,%1\n\tsbbl %0,%0" :"=r" (oldbit),"=m" (ADDR) :"Ir" (nr) : "memory"); return oldbit; } static __inline__ int test_and_clear(int nr, volatile void *addr) { int oldbit; __asm__ __volatile__( "lock ; " "btrl %2,%1\n\tsbbl %0,%0" :"=r" (oldbit),"=m" (ADDR) :"Ir" (nr) : "memory"); return oldbit; } #endif *** MY_FILE.C *** /* ------------------------------------------------------- *\ * mutex_lock(int resource_id) * * Waits until resource is avaliable, locks it and then returns * ------------------------------------------------------- */ void mutex_lock(int n_resource_id) { if ( n_resource_id < 0 || n_resource_id > 31 ) return; while ( test_and_set(n_resource_id, &ng_mutex) ) Sleep(1); } /* ------------------------------------------------------- *\ * mutex_unlock(int resource_id) * * Unlocks a resource, we assumed it's been called by the resource "locker" * ------------------------------------------------------- */ void mutex_unlock(int n_resource_id) { if ( n_resource_id < 0 || n_resource_id > 31 ) return; test_and_clear(n_resource_id, &ng_mutex); } /* ------------------------------------------------------- *\ * Mutexes -- up to 32 "mutexes" in ng_mutex [0..31] * ------------------------------------------------------- */ static unsigned int ng_mutex = 0; #define MUTEX_FIELD_HASH 0 /* ------------------------------------------------------- *\ * Variables needing thread safety * ------------------------------------------------------- */ static t_field_hash* pg_field_hash = NULL; static int pg_field_hash_references = 0; /* ------------------------------------------------------- *\ * PHP_MINIT_FUNCTION * ------------------------------------------------------- */ PHP_MINIT_FUNCTION(dvdaf) { mutex_lock(MUTEX_FIELD_HASH); { if ( ! pg_field_hash ) { pg_field_hash = malloc(gp_field_count * sizeof(t_field_hash)); pg_field_hash_references = 1; // calculate hash } else { pg_field_hash_references++; } } mutex_unlock(MUTEX_FIELD_HASH); return SUCCESS; } /* ------------------------------------------------------- *\ * PHP_MSHUTDOWN_FUNCTION * ------------------------------------------------------- */ PHP_MSHUTDOWN_FUNCTION(dvdaf) { mutex_lock(MUTEX_FIELD_HASH); { if ( --pg_field_hash_references <= 0 ) { free(pg_field_hash); pg_field_hash = NULL; pg_field_hash_references = 0; } } mutex_unlock(MUTEX_FIELD_HASH); return SUCCESS; } --- ## #1330 — Derick Rethans — 2003-05-07T04:01:17+00:00 URL: https://externals.io/message/1323#1330 · In reply to: #1324 > > […] > > Seconded. Thirded Derick -- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ --- ## #1343 — Moriyoshi Koizumi — 2003-05-07T12:47:21+00:00 URL: https://externals.io/message/1323#1343 · In reply to: #1328 Dan Kalowsky wrote: > Consider this a me fourthed message. > > This still is one of my biggest developer annoyances... bundling of extra > software. Then how about getting rid of expat and libxml altogether from the php5 branch? bunding a modified version of libgd makes sense to me though. Moriyoshi --- ## #1368 — Zeev Suraski — 2003-05-08T08:34:15+00:00 URL: https://externals.io/message/1323#1368 · In reply to: #1323 At 01:17 07/05/2003, Edin Kadribasic wrote: >Sterling, > >You have just added 3.5 MB of source into the PHP code tree despite your >assurances that libxml was only "slightly" bigger than expat which takes >up "only" 432 KB. > >This is IMHO completely unnecessary as libxml comes preinstalled as a >shared library on most modern Unix systems and because it adds bloat to >PHP distribution. Our target audience is not just modern Unix systems. And with all due respect to modern Unix systems, the versioning hell they're going to is pretty similar to the way Windows looked like circa 1992, which means that if we're relying on existing libraries, we're begging for trouble. I see the seconding and thirding and fourthing of this message, but I still fail to understand why people consider the nuance of increasing the package size, something that's completely insignificant for almost all of our users, as a too high a price for keeping PHP on top of the recent technologies. Good XML handling is as basic as good forms handling in this day and age. Zeev --- ## #1372 — Adam Dickmeiss — 2003-05-08T09:48:54+00:00 URL: https://externals.io/message/1323#1372 · In reply to: #1368 > At 01:17 07/05/2003, Edin Kadribasic wrote: > > […] > > Our target audience is not just modern Unix systems. And with all due > respect to modern Unix systems, the versioning hell they're going to is > pretty similar to the way Windows looked like circa 1992, which means that > if we're relying on existing libraries, we're begging for trouble. > I see the seconding and thirding and fourthing of this message, but I still > fail to understand why people consider the nuance of increasing the package > size, something that's completely insignificant for almost all of our > users, as a too high a price for keeping PHP on top of the recent > technologies. Good XML handling is as basic as good forms handling in this > day and age. I don't worry about the bundling size, really. What I worry about is having multiple versions of a library on a system. For example, I once got VERY confused because I had a PHP module as well as another Apache module using the "same" library, which wasnt't the same. One of them was using a shared library; one was statically linked.. The system would call "randomly" depening on the order in which Apache forked and used one of the two modules. Very confusing. Very wrong. There is a run time penaly of having two relatively big SO's too. libxml/libxml2 is a fairly big one. Would PHP maintainers, then update their CVS once in a while to reflect the newest updaes? Seems like the wrong thing to me. And wrong on Windows too.. We too ship YAZ as both windows and Unix and is now using libxml2. I would never bundle the source with that. However, what we do bundle is the libxml dll (and iconv) on Windows. Bundling _may_ be good for binary dists. Not for source unless the circumstances are very special (licensing, etc.). libxml has a licence that works with PHP and it's so widely available. The next step is that people will bundle GNU libc. -- Adam > Zeev > > > -- > > -- Adam Dickmeiss mailto:adam@indexdata.dk http://www.indexdata.dk Index Data T: +45 33410100 Mob.: 212 212 66