Linux-Development-Sys Digest #172, Volume #8 Tue, 26 Sep 00 01:13:13 EDT
Contents:
Re: POSIX named semaphores on Linux ? (Stephane Richard)
Linux Stack Sizes? (0/1) (MeekGeek)
Re: Linux Stack Sizes? (0/1) (MeekGeek)
[?] how to configure glibc-2.0.7 without fpu codes? (jauming)
Re: Linux Stack Sizes? (0/1) (Pete Zaitcev)
Re: Message distribution manager / server (Christopher Browne)
Re: Linux Stack Sizes? (0/1) ("Paul D. Smith")
Re: Message distribution manager / server (Alexander Viro)
Re: Linux Stack Sizes? (MeekGeek)
Re: How to intercept selected system calls ("Arthur H. Gold")
----------------------------------------------------------------------------
From: Stephane Richard <[EMAIL PROTECTED]>
Subject: Re: POSIX named semaphores on Linux ?
Date: Tue, 26 Sep 2000 01:09:55 GMT
I'm using sem_init() as a POSIX semaphore under a Linux system and with
a parameter to decide to use process sharing or not.
It seems that I have some problems with it anyway. I don't know why.
I didn't find any open_sem() under man pages of 6.2
Stef.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Mon, 25 Sep 2000 10:56:50 -0400, Stephane St-Hilaire
> <[EMAIL PROTECTED]> wrote:
> >
> >Is there an implementation of the POSIX named semaphore available on
> >Linux ? I'm running 2.2.14 and I get "function not implemented" when
> >calling open_sem(). Any ideas ?
>
> The bleeding edge POSIX semaphores are not available; use traditional
> UNIX semaphores if you need process sharing.
>
--
_________________________________________________
Stephane Richard
Kasenna Inc. Redefining Broadband Video!
(650) 943 8702 [EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Linux Stack Sizes? (0/1)
Date: Tue, 26 Sep 2000 02:10:10 GMT
I develop a large server application that we're in the process of
porting to Solaris and Linux. To make this story short, let's just
say I need to partition the program stack for my own needs.
I found that I only had access to a little more than 6K before my
program would crash, SIGSEGV. It's as if I'm only getting an 8K
stack, fixed, with the system/compiler/runtime lib using about 1500
bytes by the time I get to main().
I started factoring out code to narrow it down, and was left with a
simple test program. I will include that below.
I need LOTS of stack. We have a cross-platform non-preemptive kernel
(coroutine package) that allocates "task" stacks from the main
program's stack. Therefore, it is the sum of many, possible 1000 or
more, tasks' stacks. These stacks are typically 20-30K each.
The machine can be assumed to be dedicated to running this server
application, and can be assumed to have at least 1GB of physical RAM.
But I need a chunk of that for stacks (perhaps 50MB). All I can seem
to get under Linux, with a GCC 2.95.2 build, is about 6.5KB for stack.
Is there a linker option, compiler directive, executable editor, or
something similar, that will allow me to specify a larger stack?
There must be some way for me to get more than 6K of usable stack
space! :-)
Does Linux support the "guard pages" concept implemented by NT on
Intel processors?
One other idea I had was to use PThreads to create a new thread,
presumable specifying a large stack at thread creation time, if that's
possible from PThreads. Then have it allocate the task stacks from
its large thread stack.
Anyhow, the following program crashes if I specify anything more than
about 6K, such as the default if you just run it. Also attached with
a makefile.
Thanks,
M
========================================================
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define TOUCHSIZE 1024
static char * TouchAllStack(unsigned long size)
{
char c;
static char * p = &c;
static unsigned long totalsize = size;
p = (char *) (((unsigned long)p) & ~7); // 8-byte align
printf("Allocating %ul bytes from stack ending at: %08X\n",
size, (unsigned long) p);
do {
p -= TOUCHSIZE;
// Now, check access to stack memory
// and reference guard pages (Windows).
c = *p; // try reading
*p = c; // try writing
printf("Touched %lu bytes of stack at address:
%08X\n",
totalsize-size+TOUCHSIZE, (unsigned long) p);
} while ((size -= TOUCHSIZE) >= TOUCHSIZE);
p -= TOUCHSIZE; // round down to next complete TOUCHSIZE bytes
memset(p,0,size);
return p;
}
#define DEFAULT_STACK (256*1024UL)
#define MIN_STACK 8192UL // 16384UL
int main(int argc, char *argv[])
{
char * pStack = NULL;
int rc;
unsigned long MaxStack = DEFAULT_STACK;
if (argc > 1)
MaxStack=(unsigned long) atol(argv[1]);
if (MaxStack < MIN_STACK)
MaxStack = DEFAULT_STACK;
pStack = TouchAllStack(MaxStack);
return 0;
}
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: Tue, 26 Sep 2000 03:11:11 GMT
On Tue, 26 Sep 2000 02:10:10 GMT, MeekGeek <[EMAIL PROTECTED]>
wrote:
>I develop a large server application that we're in the process of
>porting to Solaris and Linux. To make this story short, let's just
>say I need to partition the program stack for my own needs.
>
>I found that I only had access to a little more than 6K before my
>program would crash, SIGSEGV. It's as if I'm only getting an 8K
>stack, fixed, with the system/compiler/runtime lib using about 1500
>bytes by the time I get to main().
>
>I started factoring out code to narrow it down, and was left with a
>simple test program. I will include that below.
>
>I need LOTS of stack. We have a cross-platform non-preemptive kernel
>(coroutine package) that allocates "task" stacks from the main
>program's stack. Therefore, it is the sum of many, possible 1000 or
>more, tasks' stacks. These stacks are typically 20-30K each.
>
>The machine can be assumed to be dedicated to running this server
>application, and can be assumed to have at least 1GB of physical RAM.
>But I need a chunk of that for stacks (perhaps 50MB). All I can seem
>to get under Linux, with a GCC 2.95.2 build, is about 6.5KB for stack.
>
>Is there a linker option, compiler directive, executable editor, or
>something similar, that will allow me to specify a larger stack?
>There must be some way for me to get more than 6K of usable stack
>space! :-)
Okay, I found the rlimit stuff, including
getrlimit/setrlimit(RLIMIT_STACK, ...). I modified my test program to
call getrlimit, which returned a soft limit of 16MB and a hard limit
of RLIM_INFINITY. Since it was reporting a soft limit of 16MB, and I
was seeing about 8K, I figured setting the limit to RLIM_INFINITY was
pointless, but I tried it anyway. It was. It still stops printing
messages at about 6.5 K. I set the TOUCH incremental value in my test
program to only 8 bytes and repeated it, and it got to 6912 and core
dumped with a SEGV.
So that limit seems to be getting ignored too.
Any ideas?
M.
>Does Linux support the "guard pages" concept implemented by NT on
>Intel processors?
>
>One other idea I had was to use PThreads to create a new thread,
>presumable specifying a large stack at thread creation time, if that's
>possible from PThreads. Then have it allocate the task stacks from
>its large thread stack.
>
>Anyhow, the following program crashes if I specify anything more than
>about 6K, such as the default if you just run it. Also attached with
>a makefile.
>
>Thanks,
>M
>
>========================================================
>
>#include <stdio.h>
>#include <stdlib.h>
>#include <string.h>
>
>#define TOUCHSIZE 1024
>static char * TouchAllStack(unsigned long size)
>{
> char c;
> static char * p = &c;
> static unsigned long totalsize = size;
>
> p = (char *) (((unsigned long)p) & ~7); // 8-byte align
>
> printf("Allocating %ul bytes from stack ending at: %08X\n",
> size, (unsigned long) p);
>
> do {
> p -= TOUCHSIZE;
> // Now, check access to stack memory
> // and reference guard pages (Windows).
> c = *p; // try reading
> *p = c; // try writing
> printf("Touched %lu bytes of stack at address:
>%08X\n",
> totalsize-size+TOUCHSIZE, (unsigned long) p);
> } while ((size -= TOUCHSIZE) >= TOUCHSIZE);
>
> p -= TOUCHSIZE; // round down to next complete TOUCHSIZE bytes
> memset(p,0,size);
> return p;
>}
>
>#define DEFAULT_STACK (256*1024UL)
>#define MIN_STACK 8192UL // 16384UL
>int main(int argc, char *argv[])
>{
> char * pStack = NULL;
> int rc;
>
> unsigned long MaxStack = DEFAULT_STACK;
>
> if (argc > 1)
> MaxStack=(unsigned long) atol(argv[1]);
> if (MaxStack < MIN_STACK)
> MaxStack = DEFAULT_STACK;
>
> pStack = TouchAllStack(MaxStack);
>
> return 0;
>}
------------------------------
From: jauming <[EMAIL PROTECTED]>
Subject: [?] how to configure glibc-2.0.7 without fpu codes?
Date: Tue, 26 Sep 2000 03:24:16 GMT
[?] how to configure glibc-2.0.7 without fpu codes?
[?] how to configure glibc-2.0.7 without fpu codes?
because "--without-fp" or "--nfp" doesn't work :<
thanks in advanced!:)
--
--
regards
--
--
regards
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Pete Zaitcev)
Subject: Re: Linux Stack Sizes? (0/1)
Date: Tue, 26 Sep 2000 03:48:30 GMT
> I need LOTS of stack. We have a cross-platform non-preemptive kernel
> (coroutine package) that allocates "task" stacks from the main
> program's stack. Therefore, it is the sum of many, possible 1000 or
> more, tasks' stacks. These stacks are typically 20-30K each.
Why don't you just use NSPR (Mozilla runtime).
If you want to make your own mistakes in your own very propritary
code then just check out how it's done by others. Pthreads may
not necesserily be a good idea as they create system-visible
threads. Find an obsolete package with user space threads,
such as linuxthreads, cthreads, etc. Study it.
--Pete
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux,comp.os.linux.development.apps
Subject: Re: Message distribution manager / server
Reply-To: [EMAIL PROTECTED]
Date: Tue, 26 Sep 2000 03:54:42 GMT
In our last episode (Thu, 14 Sep 2000 17:05:22 -0600),
the artist formerly known as Dave Vance said:
>Can anybody tell me if there is such a thing as an Event Distribution
>Manager / Event Notification Server / Message Queue Manager / Message
>Distribution Manager / Message Notification Server.. for Linux?
>
>Basically, an entity (application, driver, whatever) that accepts messages
>from one set of applications and forwards those messages on to another set
>of applications, which have "registered" with the distribution manager to
>receive messages.
Several options are out there; see sundry URLs below for links to such
alternatives as:
a) SystemV message queues (a kernel-level MQ scheme)
b) Isect - multiplatform MOM package available under GPL and LGPL
c) http://OpenQueue.sourceforge.net - Java-based MQ system
d) Falcon MQ - Commercial package that interoperates with MSMQ
e) IBM MQSeries <http://www.hursley.ibm.com/mqseries/mq>
--
(concatenate 'string "cbbrowne" "@" "acm.org")
<http://www.ntlug.org/~cbbrowne/corbaalternatives.html#MSGQUEUE>
Smith's Test for Artificial Life:
When animal-rights activists and right-to-life protesters are marching
outside your laboratory, then you know you've definitely made progress
in your artificial life research. -- Donald A. Smith
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: 26 Sep 2000 00:17:35 -0400
Reply-To: [EMAIL PROTECTED]
This is not a problem with the maximum size of the stack.
This is a problem with your code.
This isn't even _remotely_ close to being a valid C program. I'm
actually surprised it lasts as long as it does (6K) before it crashes.
Where are you porting this _from_ that it actually works as you have it
written?
First, you are assuming that the stack lives in high memory and grows
towards low memory. You cannot assume that. There is absolutely no
reason the stack couldn't live in low memory, and grow upwards. Many
implementations of UNIX and other OSs do exactly this.
Heck, there's no reason (from a C standard point of view) the stack
couldn't live right smack dab in the middle of the memory space, and
grow randomly in both directions. I don't know of any that do this, but
it's legal. To be pedantic, there's no guarantee that you even _have_ a
stack in the C standard, and some implementations don't (as such).
Second, you are assuming that any memory below your stack can
arbitrarily be written on. That's totally broken. The stack could
well be allocated only as needed by function calls, and memory beyond
what's been used is simply not available (hence traps if you try to
access it).
You will have to write a valid C program to make this work. The
simplest and most portable way is to use the heap (malloc) instead of
the stack. I'm really not clear on why you must use the stack instead
of the heap; memory is memory is memory. With sizes as large as you
seem to want surely the overhead of invoking malloc() once is completely
negligible.
If you _must_ have it in the stack, you're going to have to actually
_allocate_ that much stack! You can't simply use it without previously
telling the compiler and/or runtime system you will need it.
For example, you could use alloca(). This smells like malloc(), but it
allocates memory from the stack instead of the heap (no free()
necessary). While this isn't a standard C function, it's supported by
GCC which runs on almost any UNIX system. Also, most other UNIX
compilers and OS's support it (certainly Solaris does, even if you use
SPARCWorks instead of GCC). There _are_ platforms that don't (can't)
support alloca(), however.
If you can't do that, and your compiler supports the 1999 ISO C
standard, you can use variable size arrays (even though this is standard
and alloca() isn't, I still list alloca() as more portable because not
too many compilers support 1999 ISO C yet, while almost all support
alloca()). GCC supports these, although I'm not sure if they are 100%
standard yet. They're standard enough for you; there just may be some
weird corner cases that are non-standard.
If you can't do that, you will have to provide some kind of maximum
static value for the size of the array and just fail if you need more
than that.
If you can't do any of those things, AFAICT you're SOL and you can't
port your program to UNIX, or probably most any other platform. Sorry.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux,comp.os.linux.development.apps
Subject: Re: Message distribution manager / server
Date: 26 Sep 2000 00:30:50 -0400
In article <66Vz5.48823$[EMAIL PROTECTED]>,
Christopher Browne <[EMAIL PROTECTED]> wrote:
>In our last episode (Thu, 14 Sep 2000 17:05:22 -0600),
>the artist formerly known as Dave Vance said:
>>Can anybody tell me if there is such a thing as an Event Distribution
>>Manager / Event Notification Server / Message Queue Manager / Message
>>Distribution Manager / Message Notification Server.. for Linux?
>>
>>Basically, an entity (application, driver, whatever) that accepts messages
>>from one set of applications and forwards those messages on to another set
>>of applications, which have "registered" with the distribution manager to
>>receive messages.
>
>Several options are out there; see sundry URLs below for links to such
>alternatives as:
>a) SystemV message queues (a kernel-level MQ scheme)
>b) Isect - multiplatform MOM package available under GPL and LGPL
>c) http://OpenQueue.sourceforge.net - Java-based MQ system
>d) Falcon MQ - Commercial package that interoperates with MSMQ
>e) IBM MQSeries <http://www.hursley.ibm.com/mqseries/mq>
Ouch. If you are game for real fun - let's port plumber.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes?
Date: Tue, 26 Sep 2000 04:49:24 GMT
On Tue, 26 Sep 2000 03:48:30 GMT, [EMAIL PROTECTED] (Pete Zaitcev)
wrote:
>Why don't you just use NSPR (Mozilla runtime).
>
>If you want to make your own mistakes in your own very propritary
>code then just check out how it's done by others. Pthreads may
>not necesserily be a good idea as they create system-visible
>threads. Find an obsolete package with user space threads,
>such as linuxthreads, cthreads, etc. Study it.
I have seen several good packages. However, I already had one (and it
was probably written long before NSPR -- written sometime in 1990).
It's coded, and it works, and we've been using it on MacOS, WinNT,
Solaris and the only problem with Linux is that I don't seem to get
more than just under 7K of stack accessible from my mainline.
Did you look at the short program I posted? It's just a simple
program that reads and writes stack locations until it runs out of
stack. I don't reach 7K.
This isn't an issue of which package to use or how to do something. I
suppose I could pull the NSPR/Mozilla makefile and see if there's a
linker option specified in the Linux build that I haven't seen
before... But if they don't use real stack allocated from their
mainline's stack, that won't turn up anything. After 10 years, we're
not about to switch tasking packages... :-) What we have now is nice
and mature and stable. I'm 99% of the way there -- I just need to get
past this system-level problem.
Are you aware of any linker options, runtime calls, etc that could
bump the stack size higher? Any idea why I'm not getting my
RLIMIT_STACK limit?
Thanks again,
M.
___________________
If anyone has an answer to this, I need it quick. It's now a problem
blocking further development and testing.
The bottom line: How can I run the short program below with a size,
say, of 1 MB, without SEGV crash? GCC 2.95.2, under RedHat Linux 6.2.
More info: I develop a large server application that we're in the
process of porting to Solaris and Linux. To make this story short,
let's just say I need to partition the program stack for my own needs,
and that requires more than a basic stack size.
I found that I only had access to a little more than 6K before my
program would crash, SIGSEGV. It's as if I'm only getting an 8K
stack, fixed, with the system/compiler/runtime lib using about 1500
bytes by the time I get to main().
I started factoring out code to narrow it down, and was left with a
simple test program. I will include that below.
I need lots of stack. We have a cross-platform non-preemptive kernel
(coroutine package) that allocates "task" stacks from the main
program's stack. Therefore, it is the sum of many, possible 1000 or
more, tasks' stacks. These stacks are typically 20-30K each.
The machine can be assumed to be dedicated to running this server
application, and can be assumed to have at least 1GB of physical RAM.
But I need a chunk of that for stacks (perhaps 50MB). All I can seem
to get under Linux, with a GCC 2.95.2 build, is about 6.5KB for stack.
Is there a linker option, compiler directive, executable editor, or
something similar, that will allow me to specify a larger stack?
There must be some way for me to get more than 6K of usable stack
space! :-)
Okay, I just found the rlimit stuff, including getrlimit /
setrlimit(RLIMIT_STACK, ...). I modified my test program to
call getrlimit, which returned a soft limit of 16MB and a hard limit
of RLIM_INFINITY. Since it was reporting a soft limit of 16MB, and I
was seeing about 8K, I figured setting the limit to RLIM_INFINITY was
pointless, but I tried it anyway. It was. It still stops printing
messages at about 6.5 K. I set the TOUCH incremental value in my test
program to only 8 bytes and repeated it, and it got to 6912 and core
dumped with a SEGV.
So that limit seems to be getting ignored too. Any other ideas?
BTW, does Linux support the "guard pages" concept implemented by NT on
Intel processors? Judging by the rlimit description, it looks like
this should be working now.
One other idea I had was to use PThreads to create a new thread,
presumable specifying a large stack at thread creation time, if that's
possible from PThreads. Then have it allocate the task stacks from
its large thread stack. But it doesn't look like the pthreads calls
support specifying a stack size.
Anyhow, the following program crashes if I specify anything more than
about 6K, such as the default if you just run it without an argument.
Any help would be much appreciated.
Thanks,
M
========================================================
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define TOUCHSIZE 1024
static char * TouchAllStack(unsigned long size)
{
char c;
static char * p = &c;
static unsigned long totalsize = size;
p = (char *) (((unsigned long)p) & ~7); // 8-byte align
printf("Allocating %ul bytes from stack ending at: %08X\n",
size, (unsigned long) p);
do {
p -= TOUCHSIZE;
// Now, check access to stack memory
// and reference guard pages (Windows).
c = *p; // try reading
*p = c; // try writing
printf("Touched %lu bytes of stack at address:
%08X\n",
totalsize-size+TOUCHSIZE, (unsigned long) p);
} while ((size -= TOUCHSIZE) >= TOUCHSIZE);
p -= TOUCHSIZE; // round down to next complete TOUCHSIZE bytes
memset(p,0,size);
return p;
}
#define DEFAULT_STACK (256*1024UL)
#define MIN_STACK 8192UL // 16384UL
int main(int argc, char *argv[])
{
char * pStack = NULL;
int rc;
unsigned long MaxStack = DEFAULT_STACK;
if (argc > 1)
MaxStack=(unsigned long) atol(argv[1]);
if (MaxStack < MIN_STACK)
MaxStack = DEFAULT_STACK;
pStack = TouchAllStack(MaxStack);
return 0;
}
------------------------------
Date: Mon, 25 Sep 2000 22:31:22 -0500
From: "Arthur H. Gold" <[EMAIL PROTECTED]>
Subject: Re: How to intercept selected system calls
aslin wrote:
>
> Hello,
> I wanted to do something like this:
> intercept OPEN system call in a user-level process to
> check file if it is compressed, and decompress in other file
> and run original open with this new file name;
> I found many examples how to do thing like this, but all of them were
> kernel modules. I don't like.. I want it a user-level, as Catcher does
> from the UFO Global File System.
> I know general concepts, but I need some help;
> especialy example how to do it in user application, not in the kernel
> module.
> Thanks for any suggestions how to do it.
>
> PS: I found something about the UFO GFS
> in paper: "Extending the Operating System at the User Level:
> the UFO Global File System" Proceedings of the USENIX 1997.
> Annual Technical Conference.
>
> --
> -----------------------
> Szczepan Konieczny
>
> e-mail: [EMAIL PROTECTED]
> -----------------------
Look for the zlibc package -- that'll either do exactly what
you need or at the very least give you something to base
your code on.
HTH,
--ag
--
Artie Gold, Austin, TX (finger the cs.utexas.edu account
for more info)
mailto:[EMAIL PROTECTED] or mailto:[EMAIL PROTECTED]
--
"I'd sooner fly another combat mission than ride the Cyclone
again" -- Joseph Heller
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
