[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rxtx
Subject:    Re: [Rxtx] performance compromises
From:       cowwoc <cowwoc () bbs ! darktech ! org>
Date:       2009-05-27 15:01:45
Message-ID: 4A1D55D9.7040209 () bbs ! darktech ! org
[Download RAW message or body]

Steffen DETTMER wrote:
>> or if the thread was interrupted, 
> 
> No, AFAIK, this leads to an exception (and probably an
> `undefined' state of bytes in the buffer). Beside, that this is
> more or less a `cannot happen situation' (because: how to
> interrrupt a thread which is in a blocking JNI function call?).

	Either the JNI code checks the Thread.interrupted() flag, or cancel() 
invokes native code for interrupted an ongoing read operation. Anyway, 
if it's possible for sockets (and it is) then it should be possible for 
other types.

> But reading zero bytes because requested zero bytes is not an
> exception.

	Whether it was requested or not is not the issue. The fact that there 
are multiple possible reasons for returning 0 bytes. requires us to 
disambiguate between somehow. What happens if you request 0 bytes on a 
closed stream? Is it returning 0 because you requested zero bytes or 
because the stream is closed?

> ByteChannel has no support for timeouts. Before any call to read,
> select shall be invoked. I think in almost any case both are
> needed.

	Not sure what to tell you. This is probably a result of the fact that 
so far only sockets implement both ByteChannel and SelectableChannel. 
They'll probably add a superinterface once this combination shows up 
more often.

> I think this depends on the design. If you have a source/sink or
> proactor style design, async I/O may be suited, but if you have
> some sync approach, implementing it by async I/O probably isn't
> good.

	Fair enough, but I fail to see why timeouts are best implemented in 
terms of synchronous APIs in the first place. Historically, calls that 
block for a long while tend to lead to asynchronous event-driven models.

> Why is UDP no socket?
> In socket(2), which is quite old, since ages it works.
> Maybe in NIO3 they fix it.

	The decision to separate TCP and UDP sockets goes back to Java 1.0. 
They contain different methods and have different capabilities. I don't 
foresee them getting merged anytime soon.

> IMHO, this is just another way of saying `you can replace the
> entire functional facility completely'.
> Yeah, you can even replace the entire JVM or invent your own
> programming language :-)
> It is nice when features can be disabled or replaced completely,
> because you have a `last resort method', but this possibility
> IMHO cannot be used in an argumentation pro this features.
> This would be like saying `this feature is great. You can replace
> it by a feature doing whatever you want' which IMHO tells nothing
> :)

	The documentation doesn't talk about *replacing* anything. It says you 
can provide your own Channels. That means you can *extend* the existing 
API by adding more Channels (without throwing the old ones away). We 
won't know for sure until someone answers 
http://stackoverflow.com/questions/911780/how-do-i-define-my-own-selectablechannel 


>> Java needs to support non-POSIX operating systems that don't
>> have the same functionality which is why it can't use a
>> one-to-one mapping with POSIX.
> 
> why did they copy POSIX select(2) then?

	You asked why they didn't copy the POSIX API 100%. My point is that 
they had to abstract away POSIX capabilities in terms of what could be 
implemented across all platforms. This is why they have POSIX-like 
capability but not necessarily a one-to-one match.

> The JVM should abstract from the platform. It should be the one
> and only platform the application needs to care about.
> For example me, personally, wants to select over anything readable :)

	Maybe this makes sense under Linux, but under Windows not everything 
that is readable is selectable.

> just BTW: accept() is IMHO not specific to sockets but to multiplexing.

	How do you apply accept() to a file?

Gili
_______________________________________________
Rxtx mailing list
Rxtx@qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx
[prev in list] [next in list] [prev in thread] [next in thread]