sudo apt-get install -y kcachegrind valgrind
gcc main.c
valgrind --tool=callgrind ./a.out
# Generates a callgrind.out.<PID> file.
kcachegrind callgrind.out.1234
# Opens a GUI to visualize callgrind data.

http://www.codeproject.com/Articles/15351/Implementing-a-simple-smart-pointer-in-c

A smart pointer is a class that wraps a ‘raw’ (or ‘bare’) C++ pointer, to manage the lifetime of the object being pointed to. There is no single smart pointer type, but all of them try to abstract a raw pointer in a practical way.

Smart pointers should be preferred over raw pointers. If you feel you need to use pointers (first consider if you really do), you would normally want to use a smart pointer as this can alleviate many of the problems with raw pointers, mainly forgetting to delete the object and leaking memory.

With raw pointers, the programmer has to explicitly destroy the object when it is no longer useful.

// Need to create the object to achieve some goal
MyObject* ptr = new MyObject(); 
ptr->DoSomething(); // Use the object in some way
delete ptr; // Destroy the object. Done with it.
// Wait, what if DoSomething() raises an exception...?

A smart pointer by comparison defines a policy as to when the object is destroyed. You still have to create the object, but you no longer have to worry about destroying it.

SomeSmartPtr<MyObject> ptr(new MyObject());
ptr->DoSomething(); // Use the object in some way.

// Destruction of the object happens, depending 
// on the policy the smart pointer class uses.

// Destruction would happen even if DoSomething() 
// raises an exception

The simplest policy in use involves the scope of the smart pointer wrapper object, such as implemented by boost::scoped_ptr or std::unique_ptr.

void f()
{
    {
       boost::scoped_ptr<MyObject> ptr(new MyObject());
       ptr->DoSomethingUseful();
    } // boost::scopted_ptr goes out of scope -- 
      // the MyObject is automatically destroyed.

    // ptr->Oops(); // Compile error: "ptr" not defined
                    // since it is no longer in scope.
}

Note that scoped_ptr instances cannot be copied. This prevents the pointer from being deleted multiple times (incorrectly). You can, however, pass references to it around to other functions you call.

Scoped pointers are useful when you want to tie the lifetime of the object to a particular block of code, or if you embedded it as member data inside another object, the lifetime of that other object. The object exists until the containing block of code is exited, or until the containing object is itself destroyed.

A more complex smart pointer policy involves reference counting the pointer. This does allow the pointer to be copied. When the last “reference” to the object is destroyed, the object is deleted. This policy is implemented by boost::shared_ptr and std::shared_ptr.

void f()
{
    typedef std::shared_ptr<MyObject> MyObjectPtr; // nice short alias
    MyObjectPtr p1; // Empty

    {
        MyObjectPtr p2(new MyObject());
        // There is now one "reference" to the created object
        p1 = p2; // Copy the pointer.
        // There are now two references to the object.
    } // p2 is destroyed, leaving one reference to the object.
} // p1 is destroyed, leaving a reference count of zero. 
  // The object is deleted.

Reference counted pointers are very useful when the lifetime of your object is much more complicated, and is not tied directly to a particular section of code or to another object.

There is one drawback to reference counted pointers — the possibility of creating a dangling reference:

// Create the smart pointer on the heap
MyObjectPtr* pp = new MyObjectPtr(new MyObject())
// Hmm, we forgot to destroy the smart pointer,
// because of that, the object is never destroyed!

Another possibility is creating circular references:

struct Owner {
   boost::shared_ptr<Owner> other;
};

boost::shared_ptr<Owner> p1 (new Owner());
boost::shared_ptr<Owner> p2 (new Owner());
p1->other = p2; // p1 references p2
p2->other = p1; // p2 references p1

// Oops, the reference count of of p1 and p2 never goes to zero!
// The objects are never destroyed!

To work around this problem, both Boost and C++11 have defined a weak_ptr to define a weak (uncounted) reference to a shared_ptr.

This answer is rather old, and so describes what was ‘good’ at the time, which was smart pointers provided by the Boost library. Since C++11, the standard library has provided sufficient smart pointers types, and so you should favour the use of std::unique_ptr, std::shared_ptr and std::weak_ptr.

There is also std::auto_ptr. It is very much like a scoped pointer, except that it also has the “special” dangerous ability to be copied — which also unexpectedly transfers ownership! It is deprecated in the newest standards, so you shouldn’t use it.

std::auto_ptr<MyObject> p1 (new MyObject());
std::auto_ptr<MyObject> p2 = p1; // Copy and transfer ownership. 
                                 // p1 gets set to empty!
p2->DoSomething(); // Works.
p1->DoSomething(); // Oh oh. Hopefully raises some NULL pointer exception.

https://en.wikipedia.org/wiki/Inter-process_communication

If you’re needing to quickly test some HTML that you’re working on, start a simple web server within any folder on your Mac. Navigate to the folder to use and enter:

The number at the end is the port to use, open your browser and visit http://localhost:8000 You can use the default of port 80 if you wish and remove the port number entirely.

When you’re finished, simply press Ctrl-C.

You can find a good dtd tutorial at following page:

http://edutechwiki.unige.ch/en/DTD_tutorial

You can create any config file under following path:

/etc/ld.so.conf.d

then run:

ldconfig -v

With those steps no need to call:
export LD_LIBRARY_PATH=/usr/local/lib

Following code creates a new subprocess per connection from the port 1005. You can show them all by ps command.

/***************************************************************************
                          main.c  -  description
                             -------------------
    begin                : Thu Jun  1 20:30:59 IST 2006
    copyright            : (C) |YEAR| by Am2006a
    email                : amitsaha.in@gmail.com
 ***************************************************************************/

/***************************************************************************
 *                                                                         *
 *   This program is free software; you can redistribute it and/or modify  *
 *   it under the terms of the GNU General Public License as published by  *
 *   the Free Software Foundation; either version 2 of the License, or     *
 *   (at your option) any later version.                                   *
 *                                                                         *
 ***************************************************************************/

#ifdef HAVE_CONFIG_H
#include <config.h>
#endif

#include <stdio.h>
#include <stdlib.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#define PORT 1005   // port we're listening on



int main(void)
{
    
    struct sockaddr_in myaddr;     // server address
    struct sockaddr_in remoteaddr; // client address
    int fdmax;        // maximum file descriptor number
    int listener;     // listening socket descriptor
    int newfd,pid;        // newly accept()ed socket descriptor
    char buf[256];    // buffer for client data
    int nbytes;
    int yes=1;        // for setsockopt() SO_REUSEADDR, below
    socklen_t addrlen;
    int i, j,b_status,c=0;
	char ch[20];
    // get the listener
    if ((listener = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
        perror("socket");
        exit(1);
    }

    // lose the pesky "address already in use" error message
    if (setsockopt(listener, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(int)) == -1) {
        perror("setsockopt");
        exit(1);
    }

    // bind
    myaddr.sin_family = AF_INET;
    myaddr.sin_addr.s_addr = ntohl(INADDR_LOOPBACK);
    myaddr.sin_port = htons(PORT);
    memset(&(myaddr.sin_zero), '\0', 8);
    if (bind(listener, (struct sockaddr *)&myaddr, sizeof(myaddr)) == -1) {
        perror("bind");
        exit(1);
    }

    // listen
    if (listen(listener, 10) == -1) {
        perror("listen");
        exit(1);
    }
    printf("Server Started.Listening for incoming connections\n\n");
    while(1) {
        if ((newfd = accept(listener, (struct sockaddr *)&remoteaddr,&addrlen)) == -1) {
             perror("accept");
        }
        else
        {
            // fork a new child whenever we have a new client connection
            pid=fork();
            if(pid==0){
                //handle the client
                printf("new connection from %s on socket %d\n", inet_ntoa(remoteaddr.sin_addr),newfd);
                printf("Recieved %d bytes from the client",read(newfd,buf,sizeof(buf)));
                printf("%s",buf);

                //do any other tasks as needed
                exit(0);
            }
        }        
    }
    return 0;
}

I wanted to come up with generic way using only make (no autoconf/automake/etc) to solve the following problem:

Given a source directory with several subdirectories, have it so that running make in the top directory runs the make in all the subdirectories, potentially with dependencies so that things are built in the correct order. This should work for “make”, “make install”, “make clean”, etc.

The make manual has a good description of this (in the “Phony targets” section of all places. It says

Another example of the usefulness of phony targets is in conjunction with recursive invocations of make (for more information, see Recursive Use of make). In this case the makefile will often contain a variable which lists a number of subdirectories to be built. One way to handle this is with one rule whose command is a shell loop over the subdirectories, like this:

     SUBDIRS = foo bar baz
     
     subdirs:
             for dir in $(SUBDIRS); do \
               $(MAKE) -C $$dir; \
             done

There are a few problems with this method, however. First, any error detected in a submake is not noted by this rule, so it will continue to build the rest of the directories even when one fails. This can be overcome by adding shell commands to note the error and exit, but then it will do so even if make is invoked with the -k option, which is unfortunate. Second, and perhaps more importantly, you cannot take advantage of make’s ability to build targets in parallel (see Parallel Execution), since there is only one rule.

By declaring the subdirectories as phony targets (you must do this as the subdirectory obviously always exists; otherwise it won’t be built) you can remove these problems:

     SUBDIRS = foo bar baz
     .PHONY: subdirs $(SUBDIRS)
     subdirs: $(SUBDIRS)
     $(SUBDIRS):
             $(MAKE) -C $@
     foo: baz

Here we’ve also declared that the foo subdirectory cannot be built until after the baz subdirectory is complete; this kind of relationship declaration is particularly important when attempting parallel builds.

The point about not using loops and instead making the subdirs themselves targets seems like a good idea and works for our “make” case. Well what about “make install”? We’re already using the subdir names as targets for the normal “make”, so we can’t do the same trick exactly, but we can invent new target names

INSTALLDIRS = $(SUBDIRS:%=install-%)

install: $(INSTALLDIRS)
$(INSTALLDIRS): 
	$(MAKE) -C $(@:install-%=%) install

.PHONY: subdirs $(INSTALLDIRS)
.PHONY: install

In the first line, for each directory in SUBDIRS, we create a corresponding list of directories with “install-” prefixed (but could just as easily be a list of dirs). Next we have an install target that depends on all of them, and then we have a generic target that for each of them determines the the subdir name (by stripping off the “install-“) and does a “make install” in that directory. Last we declare these made up targets as phony.

OK, so can we use this technique for other targets too? Sure, and while we’re at it lets make our original solution for “make” use “build-” as a prefix for consistency (we are using .PHONY for all these targets, but it’s probably a good idea to have the target names not correspond to any real file/dir).

So here’s the end result, a sample Makefile for a ficticious project that has a few directories and some dependencies along with some other good ideas suggested by the GNU Coding Standards.

# example Makefile
#
SHELL = /bin/sh
INSTALL = /usr/bin/install
INSTALL_PROGRAM = $(INSTALL)
INSTALL_DATA = $(INSTALL) -m 644
include Makefile.conf

DIRS = dev ui utils doc
# the sets of directories to do various things in
BUILDDIRS = $(DIRS:%=build-%)
INSTALLDIRS = $(DIRS:%=install-%)
CLEANDIRS = $(DIRS:%=clean-%)
TESTDIRS = $(DIRS:%=test-%)

all: $(BUILDDIRS)
$(DIRS): $(BUILDDIRS)
$(BUILDDIRS):
	$(MAKE) -C $(@:build-%=%)

# the utils need the libraries in dev built first
build-utils: build-dev

install: $(INSTALLDIRS) all
$(INSTALLDIRS):
	$(MAKE) -C $(@:install-%=%) install

test: $(TESTDIRS) all
$(TESTDIRS): 
	$(MAKE) -C $(@:test-%=%) test

clean: $(CLEANDIRS)
$(CLEANDIRS): 
	$(MAKE) -C $(@:clean-%=%) clean


.PHONY: subdirs $(DIRS)
.PHONY: subdirs $(BUILDDIRS)
.PHONY: subdirs $(INSTALLDIRS)
.PHONY: subdirs $(TESTDIRS)
.PHONY: subdirs $(CLEANDIRS)
.PHONY: all install clean test

** This article is copied from http://lackof.org/taggart/hacking/make-example

pthread_once example

(https://computing.llnl.gov/tutorials/pthreads/man/pthread_once.txt)

Save following code as main.c and compile with the given command.

#include <stdio.h>
#include <pthread.h>

pthread_once_t once_control = PTHREAD_ONCE_INIT;

void library_init( void )
{
    printf ("pthread once\n");
}

void * library_entry_point1(void *p1)
{
    pthread_once( &once_control, library_init );
}

void * library_entry_point2(void *p2)
{
    pthread_once( &once_control, library_init );
}

int main ()
{
	pthread_t t1, t2;
	pthread_create(&t1, NULL, library_entry_point1, (void*)NULL);
	pthread_create(&t2, NULL, library_entry_point2, (void*)NULL);
	pthread_join(t1, NULL);
	pthread_join(t2, NULL);
	return 0;
}

compile as gcc main.c -o main -lpthread

Difference between pthread_rwlock_wrlock and pthread_mutex_lock

The pthread_mutex_lock is a general purpose lock object. The
locking thread causes all other threads that use that mutex to block.
Very simple. The pthread_rwlock_wrlock() and its sibling
pthread_rwlock_rdlock() implement a reader-writer strategy there are
many readers and a few writers. The basic issue is that you want to
allow reader threads to proceed, but you want to block writers. If a
writer thread calls pthread_rwlock_wrlock(), it will block if a reader
thread has called the rdlock, but it will also block subsequent
readers. So basically, in your question, if you only use wrlock() then
the effect is the same as the standard mutex lock, but it appears
there is more overhead associated with it.