Skip to content

Instantly share code, notes, and snippets.

@elazarl
elazarl / tcpsymcon.go
Created June 11, 2013 06:36
This code snippet demonstrate the tcp simultaneous connection feature. No one of the goroutines has a listening socket, yet, when both try to connect to each other simultaneously the connection succeeds. I've yet to understand what is this feature good for, I definitely know what is it not good for: http://golang.org/src/pkg/net/tcpsock_posix.go…
package main
import "fmt"
import "net"
var localhost = net.ParseIP("127.0.0.1")
var port1, port2 = 1220, 1229
func conwrite() {
c1, err := net.DialTCP("tcp", &net.TCPAddr{localhost, port2}, &net.TCPAddr{localhost, port1})
@elazarl
elazarl / NoLoopBackSocket.java
Created June 11, 2013 06:48
This test shows that Java will not allow a socket to connect to itself via TCP's simultaneous connection feature, by setting the source port identical to the destination port.
import org.junit.Test;
import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.net.Socket;
import java.net.SocketException;
/**
* This tests make sure Java prevents a socket from connecting to itself
* via binding to the same port it connects to
@elazarl
elazarl / poll_dev.c
Created June 18, 2013 14:33
A simple test to determine if your OS allows polling devices, e.g. /dev/null
#include <stdio.h>
#include <poll.h>
#include <fcntl.h>
int main() {
int fd = open("/dev/null", O_WRONLY);
struct pollfd pollfds = { fd, POLLOUT, 0 };
if (fd < 0) {
perror("open");
@elazarl
elazarl / bug.go
Created October 7, 2013 21:38
possible bug in Go's code generation
package bug
type returnPanic struct {
err error
}
func F() (err error) {
defer func() {
if _, ok := recover().(returnPanic); !ok {
panic(err)
@elazarl
elazarl / cb.go
Created November 5, 2013 07:21
No backtrace for Go calls across SOs
package main
func Panic() { panic("oooh, no stacktrace") }
func make_bt_longer() {
Panic()
}
func main() {
Completer = func (text string, start, end int) (replacement string, options []string) {
@elazarl
elazarl / ecdsa_sign.go
Created March 31, 2014 20:49
An ECDSA based signature scheme compatible with openssl sha256 -sign/-verify
// A signer/verifier compatible with openssl ecdsa signature scheme
//
// $ openssl ecparam -name prime256v1 -genkey -noout >ec.pem
// $ openssl ec -pubout <ec.pem >ecpub.pem
//
// and with sha256 verification
//
// $ echo a|openssl sha256 -sign ec.pem > sig.bin
// $ echo a|openssl sha256 -verify ecpub.pem -signature sig.bin
//
/**
* Usage:
* $ javac KillRegions
* $ # list all regions in cluster, search for first listed region in MYTABLE
* $ java -cp `hbase classpath`:. KillRegions -l|grep MYTABLE|head -n1 >/tmp/regions.txt
* $ # delete first regions in MYTABLE, listed above
* $ java -cp `hbase classpath`:. KillRegions </tmp/regions.txt
*/
import com.google.common.base.Charsets;
import com.google.common.collect.Lists;
@elazarl
elazarl / LongAdderBench.java
Last active August 29, 2015 14:00
Benchmark showing that sometime
/*
Welcome to the game show "lies and benchmarks".
We will present the participants a required result, and they would build a
benchmark that reaches the predetermined conclusions.
When done professionally, this activity is called "benchmarketing".
Our task for today is to prove LongAdder is slower than AtomicLong. Our
observation is, LongAdder prevents write contention to a single a atomic
@elazarl
elazarl / LongAdderBenchResult.md
Last active August 29, 2015 14:01
Results for LongAdderBench.java

By @cmpxchg16 1%-100% writes samples for LongAdderBench.java:

for  1% writes=16,000 (16 threads * 100,000 ops each=1,600,000):
  LongAdder  1.209ms
  AtomicLong 0.281ms
AtomicLong faster than LongAdder by 76.77%

for  2% writes=32,000 (16 threads * 100,000 ops each=1,600,000):
  LongAdder  2.019ms

AtomicLong 0.485ms

@elazarl
elazarl / gdbdump.sh
Created July 5, 2014 20:11
hexdump to dump memory in gdb's format
alias gdbdump='hexdump -e '\''"0x%04_ax: " 8/1 "0x%02x\t" "\n"'\'''
# hexdump format is: '"0x%04_ax: " 8/1 "0x%02x\t" "\n"'