java.util.concurrent.locks.LockSupport.parkNanos/unpark is useful ?

Protip: Don't use java.lang.Object.wait for simple sleep/wakeup logic. LockSupport.parkNanos/unpark has less overhead.

2012-01-27 01:30:34

Lgd. Viktor Klang @viktorklang

@headius Protip: avoid parking threads

2012-01-27 01:42:26

@viktorklang Why, what's wrong with parking?

2012-01-27 01:44:11

Lgd. Viktor Klang @viktorklang

@headius Context switch overhead.

2012-01-27 01:46:39

@viktorklang Well yeah, but when you gotta sleep you gotta sleep :) BTW, maybe you can help me make Fiber faster? http://t.co/aJUCdZOp

2012-01-27 01:59:49

Lgd. Viktor Klang @viktorklang

@headius What's the current bottleneck?

2012-01-27 02:04:01

@viktorklang Well, this is the fastest I've managed to make context-switching. Basically, it's always cooperatively handing off...

2012-01-27 02:05:29

@viktorklang ...but I haven't found anything faster than Exchanger to do that handoff. Anything else I should try?

2012-01-27 02:06:30

Lgd. Viktor Klang @viktorklang

@headius Try to stay with the same Thread. Greatly reduces cache traffic.

2012-01-27 02:07:52

@viktorklang Indeed, but unfortunately that's not possible. The Fiber needs to be able to pause at any time and resume the caller.

2012-01-27 02:08:34

Lgd. Viktor Klang @viktorklang

@headius Are you using the latest version? http://t.co/Ljks3TL4

2012-01-27 02:10:08

@viktorklang I'm using whatever's in JDK.

2012-01-27 02:12:13

Lgd. Viktor Klang @viktorklang

@headius In JDK-what? :-)

2012-01-27 02:12:34

@viktorklang Whatever the JRuby user is using :) The one in 1.7 has been improved?

2012-01-27 02:15:34

Lgd. Viktor Klang @viktorklang

@headius I guess it depends on which JDK7 you use. But I definitely prefer to know what code gets executed :-)

2012-01-27 02:16:42