[Devel] PKG and SHM memory

Eliot Gable egable at broadvox.net
Wed Nov 22 23:39:43 CET 2006


Is there a mechanism built into SER by which I can lock access to shared
memory so other threads cannot try to modify it while I am working with
it in a separate thread? 

 

Also, is there a way to hook into the packet sending / receiving
mechanisms without going through the transaction module (for instance,
if I want to keep my own state and transaction table)?

 

Is there a common hash table implementation in SER, or do I have to use
my own?

 

 

Eliot Gable

Operations Engineer

CCNA, CWNA, CWSP, Network+, Security+

Broadvox, LLC

1228 Euclid Avenue

Suite 390

Cleveland, OH 44115-1800

216-373-4808

 

-----Original Message-----
From: Weiter Leiter [mailto:bp4mls at googlemail.com] 
Sent: Wednesday, November 22, 2006 9:48 AM
To: Eliot Gable
Cc: devel at openser.org
Subject: Re: [Devel] PKG and SHM memory

 

 

On 11/22/06, Eliot Gable <egable at broadvox.net> wrote:


Could someone please explain what the difference is between PKG and SHM
memory in terms of module development? 


SHM cames from shared memory, while PKG from process private. 

	 

	When would I want to use SHM over
	PKG memory or vice-versa? 


When you need to keep some state over multiple requests, use SHM
(because you don't know what process will serve subsequent requests).

	 

	And why should we not just use standard C
	malloc?


Due to speed impact. However, if you need some big chunks of mem that
will remain 'static' from module init till shutdown, you can use libc's
malloc. 

WL.

	 

	Eliot Gable
	Operations Engineer
	CCNA, CWNA, CWSP, Network+, Security+ 
	Broadvox, LLC
	1228 Euclid Avenue
	Suite 390
	Cleveland, OH 44115-1800
	216-373-4808
	
	
	
	_______________________________________________
	Devel mailing list
	Devel at openser.org 
	http://openser.org/cgi-bin/mailman/listinfo/devel

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openser.org/pipermail/devel/attachments/20061122/9e591160/attachment.html


More information about the Devel mailing list