AW: AW: AW: AW: AW: AW: bzr selftest (on solaris 10): too may open files

[Voelker, Bernhard]

Vincent wrote:

> Check that you can are allowed to raise your limits:
> 
> ulimit -H -a
> ulimit -S -a

Strange news for me after several years on Solaris!  ;-|

* my ulimit is fine:

	$ ulimit -H -n
	65536
	$ ulimit -S -n
	2048

==> 64k hard, 2k soft

* but not `bzr selftest` nor my example program
  can get more than FILE*[255]:

	#include <stdio.h>
	int main(int argc, char**argv)
	{
	  int i = 0;
	  FILE *fp[10000];
	  for(i=0;i<10000; i++)
	  { 
	    fp[i] = fopen(argv[0], "r");
	    if (!fp[i])
	      break;
	  }
	  fprintf(stdout, "nofiles: %d\n", i);
	  return 0;
	}

  (the output is 253, stdout + stderr have to be added)


* a google search lead me to
  http://blogs.sun.com/ejannett/entry/get_rid_of_fopen_file

  The proposed method didn't work but the fact that this article
  is talking about the problem to be a 32-bit issue of the
  FILE structure pointed me to 2 experiments:

a) replace fopen() by open():

	==> hurray, it worked! ;-)

b) compile the example program for 64 bit:

	$ cc -xarch=v9 ...

	==> hurray, it worked! ;-)


That means that my python installation most probably uses fopen()
instead of open() - it is a 32-bit proggy:

	file  /bin/python
	/bin/python:    ELF 32-bit MSB executable SPARC Version 1,
dynamically linked,\n
	not stripped, no debugging information available

Unfortunately, I don't have an older Solaris machine (<5.10)
here for testing. Anyone?

BTW: on WinXP, I can get 512 with fopen() and open().


Bye,
Berny