[Rxtx] Questions about the Rewrite2010
adrian.crum at sandglass-software.com
Tue Mar 1 04:13:34 MST 2011
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.
On 2/28/2011 11:54 PM, Kustaa Nyholm wrote:
> 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
> 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
More information about the Rxtx