smart ptr ^ weak reference ^ atomic ref

There’s some interesting resemblance between sptr and weakref. (Will address atomic ref later ..)Background — dominant construct in both c++ and java is the 32-bit pointer, assuming 32-bit address bus.

sptr and weakref
– both “wrap” the raw ptr
– both occupy more than 32 bits
– both introduce an extra level of indirection when accessing pointee
– both were designed for clever heap memory de-allocation
– when you need a raw ptr, you can’t pass in such a super ptr.
– in each case, 2 addresses are involved –
** pointee address and sptr’s own address
** pointee address and the weakref’s own address. When you pass the weakref, you don’t clone the weakref but you clone the 32-bit address of the weakref object.

$dbproc in PWM perl database programs

Now I know where the $dbproc came from. It’s a common variable name in sybase DB-library programs. Note DB-library is the older of the 2 open-client libraries, and still used in many wall street banks.

http://manuals.sybase.com/onlinebooks/group-cnarc/cng1110e/dblib/@Generic__BookTextView/503;pt=505#X — shows a standard DB-library program

http://manuals.sybase.com/onlinebooks/group-cnarc/cng1110e/dblib/@Generic__BookTextView/34250;pt=39614
http://manuals.sybase.com/onlinebooks/group-cnarc/cng1110e/dblib/@ebt-link;pt=34250?target=%25N%15_34741_START_RESTART_N%25

sybase open client, open server, DB-library

http://manuals.sybase.com/onlinebooks/group-cnarc/cng1110e/ctref/@Generic__BookTextView/292;pt=294#X explains

The Sybase product line includes 1) servers and 2) tools for building servers:

  • SQL Server is a database server. SQL Servers manage information stored in one or more databases.
  • Open Server provides the tools and interfaces needed to create a custom server application.

SQL Server and Open Server applications are similar in some ways …But they also differ:

  • An application programmer must create an Open Server application, using Server-Library's building blocks and supplying custom code. SQL Server is complete and does not require custom code.

Open Client provides two core programming interfaces: Client-Library and DB-Library

  • Open Client Client-Library supports server-managed cursors and other new features that were added to the System 10 product line.
  • Open Client DB-Library provides support for older Open Client applications, and is a completely separate programming interface from Client-Library. DB-Library is documented in the Open Client DB-Library/C Reference Manual.

Client-Library programs also depend on CS-Library, which provides routines that are used in both Client-Library and Server-Library applications.

linux named pipe – simple experiment – inode, mtime…

Copied from http://linuxprograms.wordpress.com/2008/02/14/fifo-named-pipes-mkfifo-mknod/

Reading/ Writing data from/to a FIFO
Let’s open two terminals
In the first terminal

$ cat > fifo

we are experimenting with the FIFOThis is second line.

After opening the fifo in the second terminal for reading using cat, you will notice the above two lines displayed there.
Now open the second terminal and go to the directory containing the FIFO ‘fifo’

$ cat fifo

we are experimenting with the FIFOThis is second line.

Now keep on writing to the first terminal. You will notice that every time you press enter, the corresponding line appears in the second terminal.

Pressing CTRL+D in the first terminal terminates writing to the fifo. This also terminates the second process because reading from the fifo now generates a “BROKEN PIPE” signal. The default action for this is to terminate the process.

Let us now see the details of the file ‘fifo’

$ ls -l fifo
prw-r--r-- 1 user user 0 Feb 14 10:05 fifo

The p in the beginning denotes that it is a pipe.

Let’s see more details about the pipe using stat

$ stat fifo
File: `fifo'Size: 0 Blocks: 0 IO Block: 4096 fifo
Device: fd00h/64768d Inode: 1145493 Links: 1
Access: (0644/prw-r--r--) Uid: ( 0/ user) Gid: ( 0/ user)
Access: 2008-02-14 10:05:49.000000000 +0530
Modify: 2008-02-14 10:05:49.000000000 +0530
Change: 2008-02-14 10:05:49.000000000 +0530

If you notice carefully, FIFOs just like a normal file possess all the details like inode number, the number of links to it, the access, modification times, size and the access permissions.

As in the case of pipes, there can be multiple readers and writers to a pipe. Try opening multiple terminals to read from and write to a pipe.

3 differences – perl vs c++

Someone asked me this questions.

My answer: strongly typed vs dynamically typed. strings and numbers.. You can have an array of mixed data types. Not practical in c++ — a subversion of strict type control.

My answer: not compiled but interpreted — run-time performance

My answer: no pointers in perl, no direct access to hardware

–other key differences I should have included
– c++ can leverage lots of legacy C code, and call C system functions directly
– c++ is  memory efficient.
– c++ object code is platforms-specific
– class-support, vtbl,
– OO supports larger projects. Somehow OO perl isn’t catching on

blocking calls in MOM

Synchronous means blocking API. “Synchronous” is really a overcomplicated term.

Q: What calls are blocking in a MOM context?
A: when a producer contacts a broker, it blocks until it gets a broker ack.
A: when broker contacts any consumer, at the TCP level it has to block to establish the connection

Thread.java methods – 2+1+1 types

For a novice, It's instructive to classify Thread.java methods —

1) Methods affecting the executing jvm thread, always static methods – sleep, yield
2) Methods affecting “this” which is a Thread object linked to a jvm thread. Always non-static methods – targetThread.set/getUncaughtExceptionHandler(), targetThread.isDaemon()

Those are the 2 most common types of Thread.java methods, but there are also —

3) Methods (very special) affecting b_o_t_h — targetThread.join(), targetThread.interrupt()

4) Methods affecting no particular thread, but entire JVM — getAllStackTraces(), set/getDefaultUncaughtExceptionHandler()

threadA triggering immediate reaction on blocked threadB

Note this write-up is about _immediate_ reaction in a _blocking_ thread B.

If B is not blocking, then reaction can’t be immediate.

1) If executing thread A calls “threadB.interrupt()”, B often gets an immediate exception. This is the original “simple thread communication”, before JDK 5 added …

1b) throwing an exception in a Callable task (on Thread A) will cause the blocking thread B to throw exception while blocking on futureA.get()

Also,
2) threadA.join() will cause the current thread B to block until A exits. When the operation in A exits, the exit will release ThreadB.

I believe all of them rely on
3) wait/notify