libxml bundling View as Markdown

In my opinion this bloat should be removed.

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/

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;
  }

Dan Kalowsky dank@deadmime.org 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

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.
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