Changeset 434
- Timestamp:
- 07/17/07 12:54:36 (1 year ago)
- Files:
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
experiments/jruby-1/src/com/rubyeventmachine/EM.java
r432 r434 64 64 loopBreaker = new AtomicBoolean(); 65 65 loopBreaker.set(false); 66 myReadBuffer = ByteBuffer.allocate Direct(32*1024);66 myReadBuffer = ByteBuffer.allocate(32*1024); // don't use a direct buffer. Ruby doesn't seem to like them. 67 67 timerQuantum = 98; 68 68 } … … 127 127 if (k.isReadable()) { 128 128 SocketChannel sn = (SocketChannel) k.channel(); 129 ByteBuffer bb = ByteBuffer.allocate(16 * 1024);129 //ByteBuffer bb = ByteBuffer.allocate(16 * 1024); 130 130 // Obviously not thread-safe, since we're using the same buffer for every connection. 131 131 // This should minimize the production of garbage, though. … … 133 133 // inbound data through an SSLEngine. Hope that won't break the strategy of using one 134 134 // global read-buffer. 135 // TODO, well, no. Using a global buffer produces Java null-pointer exceptions. Is the 136 // read handler being re-entered somehow? We're missing a big performance increment here, 137 // so this has to get solved. 138 //myReadBuffer.clear(); 139 int r = sn.read(bb); 135 myReadBuffer.clear(); 136 int r = sn.read(myReadBuffer); 140 137 if (r > 0) { 141 bb.flip();138 myReadBuffer.flip(); 142 139 //bb = ((EventableChannel)k.attachment()).dispatchInboundData (bb); 143 eventCallback (((EventableChannel)k.attachment()).getBinding(), EM_CONNECTION_READ, bb);140 eventCallback (((EventableChannel)k.attachment()).getBinding(), EM_CONNECTION_READ, myReadBuffer); 144 141 } 145 142 else {