[Rxtx] Questions about the Rewrite2010

[Adrian Crum]

Unfortunately, the javax.comm API specification includes a lot of 
implementation details. That is one of the weaknesses of the 
specification in my opinion. The bottom line is, anyone wanting to use 
RxTx as a javax.comm implementation is going to expect it to do the 
things the specification says it does.

-Adrian

On 3/1/2011 7:26 AM, Steffen DETTMER wrote:
>> The javax.comm API specification requires one event monitor
>> thread per port.
> Where does it require this?
>
>     Do you mean "All the events received by this listener are generated
> by one dedicated thread that belongs to the SerialPort object. "?
>
> I think this is an implementation detail, isn't it? At least it is
> mentioned after "The current implementation only allows one listener per
> SerialPort". A bit bad that javadoc does not distinguish between API
> spec and implementation documentation. Also I don't think that
> TooManyListenersException MUST be thrown (I think it CAN be thrown).
>
>> I don't like the idea of having a thread per
>> port either, but one of the rewrite's design goals is strict
>> conformance to the specification.
> (but not necessarily on JNI layer)
>
>> The 50 mS polling interval is just a placeholder. The final
>> design of that is yet to be decided.
> I though no polling would be wanted; what could be the placeholder stand
> for? Do you mean a different interval duration or do you mean something
> completely different?
>
>> In Windows, you have two choices for I/O: overlapped and
>> non-overlapped.
>> In overlapped I/O a thread is blocked, waiting for something
>> to happen.
>> In non-overlapped I/O a thread does not block. I chose
>> non-overlapped I/O to avoid thread blocking at the OS level -
>> instead, the thread blocking is kept in Java.
> Isn't "overlapped" (asynchronous) I/O meaning that you invoke some
> ReadFile(...,&overlapped, ...)
> INSTEAD of performing a synchronous (blocking) function call blocking
> the thread?
>
> As far as I see, W32_Support.cpp uses CreateFile without
> FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O
> operations are serialized, even if the calls to the read and write
> functions specify an OVERLAPPED structure." [1] and "A synchronous
> handle behaves such that I/O function calls using that handle are
> blocked until they complete" [2]
>
> Given that CCOMTIMEOUTS get:
> "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values
> for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier
> members, specifies that the read operation is to return immediately with
> the bytes that have already been received, even if no bytes have been
> received." [3]
>
> It looks likes this implementation relies on polling, which probably
> would waste much computing power.
>
> What did I miss?
>
> oki,
>
> Steffen
>
> [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx
> [2]
> http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro
> nous_and_asynchronous_i_o_handles
> [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx
>
>
> About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue.
> http://www.ingenico.com/.
>   This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.
>   P Please consider the environment before printing this e-mail
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx