David M. Lloyd wrote:
> On 04/28/2008 01:45 PM, Outside - Karl's ACM wrote:
>> Exciting conversations this morning. ;)
>>
>> I also have a personal interest in a multithread safe, nonblocking,
>> bytecode targeting DFA (and Thompson NFA?) compiler. If such a project
>> exists or is forming I would like to become involved.
> 
> Great!
> 
>> With regards to mutating the mark / limit of buffers would anyone favor
>> method invariants that can be checked in a test pipeline and not in the
>> production pipeline? Another pattern I have used when dealing with
>> ByteBuffers is to .slice() and then move the position ahead on the
>> original buffer after the call (slightly slower than invariants).
> 
> DIRMINA-490 was all about adding this functionality (sort of a
> "consuming" slice() if you will).  I've also solved this problem with
> standard NIO ByteBuffers more times than I care to think about. :-)
> 
> Usually I just have an IoUtil class or something with a static method..
> something like this:
> 
>     // untested by the way ;-)
>     public static ByteBuffer sliceBuffer(ByteBuffer buffer, int
> sliceSize) {
>         if (sliceSize > buffer.remaining() || sliceSize <
> -buffer.remaining()) {
>             throw new BufferUnderflowException();
>         }
>         final int oldPos = buffer.position();
>         final int oldLim = buffer.limit();
>         if (sliceSize < 0) {
>             // count from end
>             buffer.position(oldPos - sliceSize);
>             try {
>                 return buffer.slice();
>             } finally {
>                 buffer.position(oldPos);
>                 buffer.limit(oldLim + sliceSize);
>             }
>         } else {
>             // count from start
>             buffer.limit(oldLim - sliceSize);
>             try {
>                 return buffer.slice();
>             } finally {
>                 buffer.position(oldPos + sliceSize);
>                 buffer.limit(oldLim);
>             }
>         }
>     }

Actually I used similar technique for some cases, but I felt
uncomfortable with it because it can't stop a user from modifying the
parent buffer's position and limit as long as it's exposed to the user.

Checking the state of the parent buffer in the filter chain can solve
the problem to some extent as Karl pointed out.  However, I would find
it's somewhat degrading user experience because it means I can't use all
the access methods in ByteBuffer at the first place even if they are
sitting down there.  Always failing methods shouldn't be exposed IMHO.
-- 
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to