[Rxtx] Questions about the Rewrite2010

[Adrian Crum]

The javax.comm API specification requires one event monitor thread per 
port. 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.

The 50 mS polling interval is just a placeholder. The final design of 
that is yet to be decided.

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.

-Adrian

On 2/28/2011 11:54 PM, Kustaa Nyholm wrote:
> Adrian,
>
> had a look at your code/rewrite and it looks rather clean/nice.
>
> I was looking at the code to gain insight (not related to the
> rewrite) into what is involved in serial port programming
> in Windows. Or rather, to refresh my memory and see how others have
> done, because I've been there done that.
>
> So my questions are just to satisfy my curiosity, not to criticize
> or suggest improvements.
>
> 1) It looks like a new thread (EventMonitor) is created for
> each Serial port, is that correct?
>
> Many people seem to try to avoid using many threads in this sort
> of situation, and like to use something like unix select().
> I personally find using threads more natural and better impedance
> match to the problem being solved here. I guess 'many people' above
>
> refers to those implementing thousands of connections and
> who cannot live with the overhead and limited number of threads
> available.
>
> 2) The EventMonitor basically polls for events at 50 msec interval?
>
> 3) There is a comment in the source code near the sleep(50) :
>
> // Sufficient up to 19200 baud
>
>
> I'm sure you thought about this carefully, so again not
> criticizing, but seeking to understand how or why, because
> at 50 msec would seem to limit through in some cases. Like
> if you send one byte and need to wait for one to return,
> then this limits speed to 200 chars/sec?
>
> 4) I've done something similar to a few years back from
> Java using JNI to access Win32 API serial port, and
> I seem to recall that I had threading issues ie when
> I submitted a read (ReadFile) and there was no data coming
> in, the thread would not only block but also consume a
> lot of CPU cycles ie it was not sleeping properly inside
> the ReadFile call when the serial port blocked.
>
> Im a bit fuzzy about the details after five years, so my question is
> have you checked if  there an issue here?
>
>
> 5) AFAIK the select() on Windows does not work serial ports
> but there is some other mechanism (events?) to implement the
> same functionality, did you consider that? Probably, so you
> decided against it, why?
>
>
> br Kusti
>
>
>
>
>
>
> _______________________________________________
> Rxtx mailing list
> Rxtx at qbang.org
> http://mailman.qbang.org/mailman/listinfo/rxtx