From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0002.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0002.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0003.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0003.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0004.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0004.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0005.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0005.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0006.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0006.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0007.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0007.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0008.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0008.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0009.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0009.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0010.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0010.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0011.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0011.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0012.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0012.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0013.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0013.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0014.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0014.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > I have created a web-start testing facility to > try an help with the duplication of the bug that I am > seeing with the PortIO device. The web start console > reports: > ---------------------------------------------------- > Devel Library > ========================================= > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > port already in use > The application may be run from: > http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp > > public static void main(String[] args) { > CommPortUtils cpu = CommPortUtils.getCommPortUtils(); > portIdInterface = cpu.getACommPortFromUser(); > > > > // SETUP SERIAL PORT: > try { > serialPortInterface = (SerialPortInterface) > portIdInterface.open("SimpleWriteRead", 1000); > } catch (PortInUseException e) { > System.out.println("port already in use"); > return; > } > > Trent: You asked: >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are > using threads. > > I am not sure if I have answered your question. The program, > produced the above output after an overnight wait. How > can I tell if the kernel is ready? > That does answer my question. Hmm. rxtx does think the port is in use. There are no other applications looking at the port? -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 04:48:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 06:48:10 -0400 Subject: [Rxtx] bugs? Message-ID: Hi All, I have made a change in the code. The problem has gone away. It is possible that my change in the code fixed something, I am not sure if this is the case, however, and testing continues. Here is the new version: public class CommPortIdentifier implements CommPortIdentifierInterface { private String PortName; private boolean Available = true; private String Owner; private CommPortInterface commport; private CommDriver RXTXDriver; static CommPortIdentifier CommPortIndex; CommPortIdentifier next; private int PortType; private final static boolean debug = false; final static Object Sync; Note that the "Sync" object is now final. This was suggested by the Intellij IDEA ide. A better understanding of why this might make a difference is contained in the Technical Report: [Manson] Manson, Jeremy and Pugh, William. Semantics of Multithreaded Java. Department of Computer Science, University of Maryland, College Park, CS-TR-4215 http://www.cs.umd.edu/users/jmanson/java/CS-TR-4215.ps A data race can occur if the non-final version of the Sync object were changed. This is outlined in Section 5, pp4, of the above report. Thus, if the field were changed, the semantics of synchronizing on Sync are probably not useful. Hence it should not harm, and indeed, should help the code. Final static fields do not have to be reloaded at synchronization points and they must be initialized by the class in which they are defined, by the class initialization process [Manson]. The question of why the program now works (better lucky than smart, I always say) remains open. - Doug From gergg at cox.net Mon Sep 25 12:37:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 25 Sep 2006 13:37:22 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: <451821E2.2020100@cox.net> Dr. Douglas Lyon wrote: > Trent Jarvi Said: >>Perhaps you are trying to open the port before the kernel is ready? Are >>you opening right after closing? The more recent versions of rxtx may >>close the port faster which could make a difference depending how you are >>using threads. An API shouldn't make a synchronous event, such as freeing a resource, into an ansynchrous activity unless it can also mediate a rendevous of any future users of such a resource. The normal use of open and close on resources in an operating system is synchronous. I think it's really not a good idea to make the close asynchronous. Some might do this to keep the application from waiting for a flush on a slow connection, or one with stuck flow control. It really should block the caller until the close completes, and let the calling environment decide that their application requires asynchronous behavior. Gregg Wonderly From ajmas at sympatico.ca Mon Sep 25 13:36:29 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 25 Sep 2006 15:36:29 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Wasn't this sorted in the trunk build, which is to be released as rxtx-2.0-8? If remember rightly it was to do with the fact the MacOS X used IOKit instead of lock files. Also the folder that lock files would be stored in on MacOS X doesn't exist by default, so confusing the RXTX. Andre > > From: Trent Jarvi > Date: 2006/09/25 Mon AM 02:14:35 EDT > To: RXTX Developers and Users > Subject: Re: [Rxtx] port in use exception > > On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > > > Hi All, > > For the longest time, I was using RXTX to dial the phone. > > Recently, I switched to the PortIO device (USB to Serial converter). > > > > If I quit from the application and restart, I get an exception, as seen > > below, on the Mac. However, trying again seems to work fine. > > As long as the application remains open, everything works well. > > > > I do close the port when I am done. > > Hmm. I am using a odd-ball version of RXTX, as you can see. > > This could be the culprit. Any ideas? > > Thanks! > > - Doug > > > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > > Java lib Version = R-testing-XTX-2.1-7pre20noLock > > trying to open:/dev/tty.usbserial > > gnu.io.PortInUseException: Unknown Application > > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > > at serialPort.Utils.init(Utils.java:62) > > at serialPort.Utils.(Utils.java:37) > > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > > at gui.run.RunButton.actionPerformed(RunButton.java:45) > > at > > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > > at > > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > > at > > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > > at > > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > > at > > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > > at > > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > > at java.awt.Component.processMouseEvent(Component.java:5554) > > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > > at java.awt.Component.processEvent(Component.java:5319) > > at java.awt.Container.processEvent(Container.java:2010) > > at java.awt.Component.dispatchEventImpl(Component.java:4021) > > at java.awt.Container.dispatchEventImpl(Container.java:2068) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at > > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > > at > > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > > at java.awt.Container.dispatchEventImpl(Container.java:2054) > > at java.awt.Window.dispatchEventImpl(Window.java:1774) > > at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > > at > > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > > at > > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > > at > > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > > hehe.. I remember making that oddball version for you :) Its not very > different from like releases at the time. > > Perhaps you are trying to open the port before the kernel is ready? Are > you opening right after closing? The more recent versions of rxtx may > close the port faster which could make a difference depending how you are > using threads. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 25 20:35:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 20:35:36 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060925193629.LTXZ10262.tomts22-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: The version that Doug was using did not create lockfiles or use the lock mechanism suggested. This was before that. We simply disabled the lockfiles as a test. On Mon, 25 Sep 2006, Andre-John Mas wrote: > Hi, > > Wasn't this sorted in the trunk build, which is to be released as > rxtx-2.0-8? If remember rightly it was to do with the fact the > MacOS X used IOKit instead of lock files. Also the folder that > lock files would be stored in on MacOS X doesn't exist by default, > so confusing the RXTX. > > Andre > >> >> From: Trent Jarvi >> Date: 2006/09/25 Mon AM 02:14:35 EDT >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] port in use exception >> >> On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> For the longest time, I was using RXTX to dial the phone. >>> Recently, I switched to the PortIO device (USB to Serial converter). >>> >>> If I quit from the application and restart, I get an exception, as seen >>> below, on the Mac. However, trying again seems to work fine. >>> As long as the application remains open, everything works well. >>> >>> I do close the port when I am done. >>> Hmm. I am using a odd-ball version of RXTX, as you can see. >>> This could be the culprit. Any ideas? >>> Thanks! >>> - Doug >>> >>> Native lib Version = R-testing-XTX-2.1-7pre20noLock >>> Java lib Version = R-testing-XTX-2.1-7pre20noLock >>> trying to open:/dev/tty.usbserial >>> gnu.io.PortInUseException: Unknown Application >>> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >>> at serialPort.Utils.init(Utils.java:62) >>> at serialPort.Utils.(Utils.java:37) >>> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >>> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >>> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >>> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >>> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >>> at gui.run.RunButton.actionPerformed(RunButton.java:45) >>> at >>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >>> at >>> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >>> at >>> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >>> at >>> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >>> at >>> javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >>> at >>> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >>> at java.awt.Component.processMouseEvent(Component.java:5554) >>> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >>> at java.awt.Component.processEvent(Component.java:5319) >>> at java.awt.Container.processEvent(Container.java:2010) >>> at java.awt.Component.dispatchEventImpl(Component.java:4021) >>> at java.awt.Container.dispatchEventImpl(Container.java:2068) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at >>> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >>> at >>> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >>> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >>> at java.awt.Container.dispatchEventImpl(Container.java:2054) >>> at java.awt.Window.dispatchEventImpl(Window.java:1774) >>> at java.awt.Component.dispatchEvent(Component.java:3869) >>> at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >>> at >>> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >>> at >>> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >>> at >>> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >>> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) >> >> >> hehe.. I remember making that oddball version for you :) Its not very >> different from like releases at the time. >> >> Perhaps you are trying to open the port before the kernel is ready? Are >> you opening right after closing? The more recent versions of rxtx may >> close the port faster which could make a difference depending how you are >> using threads. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From knute at frazmtn.com Mon Sep 25 21:27:05 2006 From: knute at frazmtn.com (Knute Johnson) Date: Mon, 25 Sep 2006 20:27:05 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <45183B99.26476.1B88224@knute.frazmtn.com> Any luck duplicating my problem? Thanks, -- Knute Johnson Molon Labe... From joachim at buechse.de Tue Sep 26 02:39:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 26 Sep 2006 10:39:15 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <451821E2.2020100@cox.net> References: <451821E2.2020100@cox.net> Message-ID: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> In the case of closing a socket/port I (partly) disagree with Greggs statement. From a user perspective, closing a resource means "I lost all interest in you". In the case where the (synchronous) close is immediate that is no problem. However in the case where it is not, this creates big problems. The application by itself has basicly no means of dealing with a blocking close. As the user has lost interest in the port he will not understand any kind of dialog regarding an already closed port, he might have even decided to close the application and see that it "hangs" on close. The right place to treat this is on the open. This is where you have the attention of the user and this is the point where it makes sense to wait. TCP/IP uses the same mechanisms. The kernel will keep connections in CLOSE_WAIT until complete shutdown or timeout without obliging the application/user to wait. Close is the natural "abort" for other blocking operations. Making close synchronous will make it block. Having the close block gains basicly nothing (from a user perspective) and makes the implementation of abort and application termination more complicated. From my experience a usefull implementation for close is a timeout based synchronous close with a rather small timeout. If the close "works" (ie no kernel/driver problem preventing it's execution) wait until it has returned. If it blocks (ie more than 1..4 seconds) return from the call. The trend for the kernel implementation of close is clearly "abort" r/w operations. It used to be wait for the end of r/w operations. Best regards, Joachim On 25.09.2006, at 20:37, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Trent Jarvi Said: >>> Perhaps you are trying to open the port before the kernel is >>> ready? Are >>> you opening right after closing? The more recent versions of >>> rxtx may >>> close the port faster which could make a difference depending how >>> you are >>> using threads. > > An API shouldn't make a synchronous event, such as freeing a > resource, into an > ansynchrous activity unless it can also mediate a rendevous of any > future users > of such a resource. The normal use of open and close on resources > in an > operating system is synchronous. I think it's really not a good > idea to make > the close asynchronous. Some might do this to keep the application > from waiting > for a flush on a slow connection, or one with stuck flow control. > It really > should block the caller until the close completes, and let the calling > environment decide that their application requires asynchronous > behavior. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Sep 26 15:29:45 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 26 Sep 2006 16:29:45 -0500 Subject: [Rxtx] port in use exception In-Reply-To: <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> Message-ID: <45199BC9.5010002@cox.net> Joachim Buechse wrote: > In the case of closing a socket/port I (partly) disagree with Greggs > statement. There are a number of issues to consider, so I appreciate your view points against mine! > From a user perspective, closing a resource means "I lost all > interest in you". In the case where the (synchronous) close is > immediate that is no problem. However in the case where it is not, > this creates big problems. The application by itself has basicly no > means of dealing with a blocking close. As the user has lost interest > in the port he will not understand any kind of dialog regarding an > already closed port, he might have even decided to close the > application and see that it "hangs" on close. It is possible for a java application to do Thread th = new Thread() { public void run() { try { port.close(); } catch( Exception ex ) { log.log( Level.WARNING, ex.toString(), ex ); } } }; th.setDaemon( true ); th.run(); and be in complete control of the asynchronous nature of the call, and not be bound by the OSes delay in closing. This, then makes it necessary for the application to track this pending close. It could, use a Future, to track the pending close, and force the block on open. But, this should be an application level design decision, not something that is the only interface to the underlying system calls. That's my request anyways. > The right place to treat this is on the open. This is where you have > the attention of the user and this is the point where it makes sense > to wait. TCP/IP uses the same mechanisms. The kernel will keep > connections in CLOSE_WAIT until complete shutdown or timeout without > obliging the application/user to wait. There are a couple of issues here. One, is that for network operations, an open port is distinctly different from a listening port. And if the listening port remains listened to, it can be opened multiple times, compared to a serial port which should typically not be shared/opened multiple times. CLOSE_WAIT means that the port has been closed, and the OS is holding the port in that state so that any attempts to reuse the port or otherwise send related traffic, will allow the OS to send a TCP_RST back to close down the offending application's, continued use of that port after the agreed apon close. This is all implementation detail about networking. Serial ports don't have the same negociated close. Close progresses, unimpeded, when the write buffer is empty. If remote flow control is asserted, there is no negociation for relief. This is why it seems interesting, to let the close happen asynchronously. In single threaded programming environments, it becomes very convenient to do this, but I don't think it's a correct behavior. When serial hardware/software is broken, and the flowcontrol never subsides, the application can hang forever. So, it might be good to have the timeout on close, but still, that value can be problematic under situations of large amounts of data at very slow rates. > Close is the natural "abort" for other blocking operations. Making > close synchronous will make it block. Having the close block gains > basicly nothing (from a user perspective) and makes the > implementation of abort and application termination more complicated. Close is an operating system detail, and rxtx, should maintain reasonable separation between what an OS provides (sync/async close) and its API. > From my experience a usefull implementation for close is a timeout > based synchronous close with a rather small timeout. If the close > "works" (ie no kernel/driver problem preventing it's execution) wait > until it has returned. If it blocks (ie more than 1..4 seconds) > return from the call. The trend for the kernel implementation of > close is clearly "abort" r/w operations. It used to be wait for the > end of r/w operations. Well, serial data can flow slowly compared to what a program can generate. So, it should be possible for an application to open a port at 300baud, send some large amount of data and block on the close, waiting for the send to complete. Gregg Wonderly From lyon at docjava.com Tue Sep 26 15:52:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 26 Sep 2006 17:52:32 -0400 Subject: [Rxtx] JSR help Message-ID: Hi All, Is there someone on this list who has JSR experience and can help to guide me through the process? Thanks! - Doug From tjarvi at qbang.org Tue Sep 26 17:49:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 17:49:57 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45183B99.26476.1B88224@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <45183B99.26476.1B88224@knute.frazmtn.com> Message-ID: On Mon, 25 Sep 2006, Knute Johnson wrote: > Any luck duplicating my problem? > > Thanks, > > Hi Knute Thanks for following up. I had missed your followup with the new threshold code but see it now. I'll try it tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Tue Sep 26 18:14:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 26 Sep 2006 18:14:48 -0600 (MDT) Subject: [Rxtx] JSR help In-Reply-To: References: Message-ID: On Tue, 26 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > Is there someone on this list who has JSR experience and can help > to guide me through the process? > Hi Doug Perhaps some folks at the Apache foundation would have more experience. Both possitive and negative. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Wed Sep 27 04:33:20 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 12:33:20 +0200 Subject: [Rxtx] port in use exception In-Reply-To: <45199BC9.5010002@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: I always appreciate a discussion based on good arguments;-) I know that Linus T. has argued several times that non-blocking close does not work. However in those cases where it does not work on the kernel level it can not be made to work on the application level neither. In my experience it is impossible to explain to a user why an application "hangs" on close. However they do understand that it may hang on open. >> From my experience a usefull implementation for close is a timeout >> based synchronous close with a rather small timeout. If the close >> "works" (ie no kernel/driver problem preventing it's execution) wait >> until it has returned. If it blocks (ie more than 1..4 seconds) >> return from the call. The trend for the kernel implementation of >> close is clearly "abort" r/w operations. It used to be wait for the >> end of r/w operations. > > Well, serial data can flow slowly compared to what a program can > generate. So, > it should be possible for an application to open a port at 300baud, > send some > large amount of data and block on the close, waiting for the send > to complete. This is the one point where I really disagree. Port.close() should never be used in the meaning of OutputStream.flush(). Port.close() is the only abort mechanism available. The native implementation should be free to throw away unsend data on close, abort reads and release the system resource as soon as possible. >> From a user perspective, closing a resource means "I lost all >> interest in you". In the case where the (synchronous) close is >> immediate that is no problem. However in the case where it is not, >> this creates big problems. The application by itself has basicly no >> means of dealing with a blocking close. As the user has lost interest >> in the port he will not understand any kind of dialog regarding an >> already closed port, he might have even decided to close the >> application and see that it "hangs" on close. > > It is possible for a java application to do > > Thread th = new Thread() { > public void run() { > try { > port.close(); > } catch( Exception ex ) { > log.log( Level.WARNING, ex.toString(), ex ); > } > } > }; > th.setDaemon( true ); > th.run(); > 1st problem) This returns immediately (even in the case where close does not block and returns within a few seconds). Hence the application has no idea of the progress of the close, it has to join the close thread or even have a callback interface to get status updates. This is what I often do, but it is neither elegant nor simple. 2nd problem) The application has to keep track of ports which are in the state of beeing closed if it wants to reuse/reopen the same ports (race conditions). 3rd problem) From what I have seen the java "process" will not unwind/ return if a java thread hangs in a kernel call (daemon or not). That problem most likely affects my prefered solution as well, but the above code "suggests" otherwise. > ...implementation detail about networking. Serial ports don't have > the same > negociated close. Close progresses, unimpeded, when the write > buffer is empty. In my experience the kernel level close may block if the USB driver is trapped in a weird situation (ie a client device not reacting). It may block even if no data remains to be send, I consider this a kernel/driver/device bug - but unfortunately changes to the kernel/ driver/device are often impossible. > If remote flow control is asserted, there is no negociation for > relief. This > is why it seems interesting, to let the close happen > asynchronously. In single > threaded programming environments, it becomes very convenient to do > this, but I > don't think it's a correct behavior. When serial hardware/software > is broken, > and the flowcontrol never subsides, the application can hang forever. I have seen cases where unplugging a USB device at the "right moment" or a buggy device that stops responding leads to a close blocking for hours. This is nothing the application can influence. Arguing, that an application should be allowed to hang if the OS/driver/hardware has bugs works in theory but not in (my) practice. I have seen cases, where (only) quitting the Java VM will unwind a hanging kernel close. I can not explain this behaviour, but I can reproduce it with a buggy USB device. Best regards, Joachim From lyon at docjava.com Wed Sep 27 05:28:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 07:28:45 -0400 Subject: [Rxtx] port in use exception - my app just won't quit In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, In my previous e-mail I had fooled myself into thinking that declaring a synchronized object as final might have been a fix to the port in use exception. Silly me. The problem has cropped up again. Just as Joachim predicted, my application will not quit when the port is in use (i.e., it cannot close the port). The second time I try to quit, it works OK. Try explaining that to a user. Oh wait, I am the only user ;) This never seemed to be a problem with the internal modem on the mac (cu.modem). And the problem only just started when I tried using the PortIO USB driver (which is not really new for me, either, it was just an upgrade to the OS since I tried it). I am now using 10.4.7. Last time I tried it, I was on 10.4.5 (I think). The note on 10.4.6 says: "Addresses USB audio issues for PowerPC Macs; for example, latency is improved." Does anybody know if PortIO USB drivers are working on 10.4.7 macs with RXTX software? My controller is from Prolific Technology Inc.. The driver is available from support http://www.prolific.com.tw/ date:2006/5/22? ? Version:v1.2.1r2 Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 06:22:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 08:22:38 -0400 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: Hi All, Joachim suggests that: "This is the one point where I really disagree. Port.close() should? never be used in the meaning of OutputStream.flush(). Port.close() is? the only abort mechanism available. The native implementation should be free to throw away unsent data on close, abort reads and release the system resource as soon as possible." This may be a good point. http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#close() Says that: Closes this output stream and releases any system resources associated with this stream. The general contract of close is that it closes the output stream. A closed stream cannot perform output operations and cannot be reopened. This last bit, a closed stream cannot be reopened is really telling. The roles of "flush" and "close" are often combined in an implementation, implicitly. They are also often (but not always) left out of the specification! I would say that is not an optimal treatment and that we can do better. For example: http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() Shows no flush close. But the code at the top of the document shows: FileOutputStream fos = new FileOutputStream("t.tmp"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeInt(12345); oos.writeObject("Today"); oos.writeObject(new Date()); oos.close(); There is no flush in the example! Technically, according to the spec, this should write out NOTHING! But it DOES WORK!! Why? But from the source code of the ObjectOutputStream.java, I see: public void close() throws IOException { flush(); clear(); bout.close(); } So, the flush is not in the specification, but it is in the implementation. As a Java programmer, I have gotten used to making the assumption that flush and close are combined and that the flush is implicit in the close. I am now starting to question my assumption. Whatever we decide, it should probably be explicit in the specification. There is no consistency on close implementations in the IO package. Check out the close on the ByteArrayOutputStream: /** * Closing a ByteArrayOutputStream has no effect. The methods in * this class can be called after the stream has been closed without * generating an IOException. *

* */ public void close() throws IOException { } Now check the FilterOutputStream: * The close method of FilterOutputStream * calls its flush method, and then calls the * close method of its underlying output stream. * * @exception IOException if an I/O error occurs. * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ public void close() throws IOException { try { flush(); } catch (IOException ignored) { } out.close(); } Perhaps something like the FilterOutputStream makes sense for us. But should we be ignoring exceptions on close? Perhaps we can close by trying to flush, then release the resource in a finally statement and STILL throw an exception to the caller. We may need a different exception for flush than for the internal close, to facilitate debugging. Thus public void close() throws IOException, PortInUseException At present, we have: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } Now, RXTXPort shows: public synchronized void close() { Is this consistent with the present specification, and if not, what should we do? Thanks! - Doug >I always appreciate a discussion based on good arguments;-) > >I know that Linus T. has argued several times that non-blocking close? >does not work. However in those cases where it does not work on the? >kernel level it can not be made to work on the application level? >neither. In my experience it is impossible to explain to a user why? >an application "hangs" on close. However they do understand that it? >may hang on open. > >>> From my experience a usefull implementation for close is a timeout >>> based synchronous close with a rather small timeout. If the close >>> "works" (ie no kernel/driver problem preventing it's execution) wait >>> until it has returned. If it blocks (ie more than 1..4 seconds) >>> return from the call. The trend for the kernel implementation of >>> close is clearly "abort" r/w operations. It used to be wait for the >>> end of r/w operations. >> >> Well, serial data can flow slowly compared to what a program can? >> generate. So, >> it should be possible for an application to open a port at 300baud,? >> send some >> large amount of data and block on the close, waiting for the send? >> to complete. > >This is the one point where I really disagree. Port.close() should? >never be used in the meaning of OutputStream.flush(). Port.close() is? >the only abort mechanism available. The native implementation should? >be free to throw away unsend data on close, abort reads and release? >the system resource as soon as possible. > >>> From a user perspective, closing a resource means "I lost all >>> interest in you". In the case where the (synchronous) close is >>> immediate that is no problem. However in the case where it is not, >>> this creates big problems. The application by itself has basicly no >>> means of dealing with a blocking close. As the user has lost interest >>> in the port he will not understand any kind of dialog regarding an >>> already closed port, he might have even decided to close the >>> application and see that it "hangs" on close. >> >> It is possible for a java application to do >> >> Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >> }; >> th.setDaemon( true ); >> th.run(); >> > >1st problem) This returns immediately (even in the case where close? >does not block and returns within a few seconds). Hence the? >application has no idea of the progress of the close, it has to join? >the close thread or even have a callback interface to get status? >updates. This is what I often do, but it is neither elegant nor simple. >2nd problem) The application has to keep track of ports which are in? >the state of beeing closed if it wants to reuse/reopen the same ports? >(race conditions). >3rd problem) From what I have seen the java "process" will not unwind/ >return if a java thread hangs in a kernel call (daemon or not). That? >problem most likely affects my prefered solution as well, but the? >above code "suggests" otherwise. > >> ...implementation detail about networking. Serial ports don't have? >> the same >> negociated close. Close progresses, unimpeded, when the write? >> buffer is empty. > >In my experience the kernel level close may block if the USB driver? >is trapped in a weird situation (ie a client device not reacting). It? >may block even if no data remains to be send, I consider this a? >kernel/driver/device bug - but unfortunately changes to the kernel/ >driver/device are often impossible. > >> If remote flow control is asserted, there is no negociation for? >> relief. This >> is why it seems interesting, to let the close happen? >> asynchronously. In single >> threaded programming environments, it becomes very convenient to do? >> this, but I >> don't think it's a correct behavior. When serial hardware/software? >> is broken, >> and the flowcontrol never subsides, the application can hang forever. > >I have seen cases where unplugging a USB device at the "right moment"? >or a buggy device that stops responding leads to a close blocking for? >hours. This is nothing the application can influence. Arguing, that? >an application should be allowed to hang if the OS/driver/hardware? >has bugs works in theory but not in (my) practice. I have seen cases,? >where (only) quitting the Java VM will unwind a hanging kernel close.? >I can not explain this behaviour, but I can reproduce it with a buggy? >USB device. > >Best regards, >Joachim > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 27 07:03:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 15:03:48 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> I strongly opt to NOT call OutputStream.flush() in the implementation of Port.close(). We COULD call it in OutputStream.close() even though I would argue not to do it to motivate clean coding. Flush has no timeout sematics. Calling OutputStream.flush() in Port.close() effectively kills the only abort mechanism that exist. I am aware, that many Java stream implementations call flush in the close. Especially the higher level ones. This is all nice and handy until you see the results in the real world. Missing flush calls and flushes at the wrong moment are the source of 50% of performance problems in network applications. I think it's a very bad idea because relying on flush to get data delivered doesn't work anyway. In most out of lab scenarios only one assumption holds: If the other side (receiving application, not network stack) hasn't checked and confirmed it, it didn't arrive. In my opinion a SerialPort should react like a Socket. This is the closest widely known equivalent existing in the Java standard distribution. Calling close on a TCP-Socket (not the Outputstream of the Socket!) closes this socket immediately without calling flush. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > Hi All, > Joachim suggests that: > "This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsent data on close, abort reads and release > the system resource as soon as possible." > > This may be a good point. > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > OutputStream.html#close() > Says that: > Closes this output stream and releases any system > resources associated with this stream. The > general contract of close is that it closes the > output stream. A closed stream cannot perform > output operations and cannot be reopened. > > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an > implementation, > implicitly. They are also often (but not always) left out of the > specification! > > I would say that is not an optimal treatment and that we can do > better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ > ObjectOutputStream.html#close() > Shows no flush close. But the code at the top of the document shows: > FileOutputStream fos = new FileOutputStream("t.tmp"); > ObjectOutputStream oos = new ObjectOutputStream(fos); > > oos.writeInt(12345); > oos.writeObject("Today"); > oos.writeObject(new Date()); > > oos.close(); > > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? > > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the > implementation. > > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. > > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The > methods in > * this class can be called after the stream has been closed > without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } > > Now check the FilterOutputStream: > * The close method of FilterOutputStream > * calls its flush method, and then calls the > * close method of its underlying output stream. > * > * @exception IOException if an I/O error occurs. > * @see java.io.FilterOutputStream#flush() > * @see java.io.FilterOutputStream#out > */ > public void close() throws IOException { > try { > flush(); > } catch (IOException ignored) { > } > out.close(); > } > > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. > > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException > > At present, we have: > public interface CommPortInterface { > /** > * @return the name of this port. > */ > String getName(); > > /** > * @return a string representation of this port. > */ > String toString(); > > /** > * Closes this communications port. Further methods on this > object will > * throw IllegalStateException. All PortOwnershipListeners > will be > * notified of this change of ownership. > */ > void close(); > } > > > Now, RXTXPort shows: > public synchronized void close() { > > Is this consistent with the present specification, and if not, what > should > we do? > > Thanks! > - Doug > > >> I always appreciate a discussion based on good arguments;-) >> >> I know that Linus T. has argued several times that non-blocking close >> does not work. However in those cases where it does not work on the >> kernel level it can not be made to work on the application level >> neither. In my experience it is impossible to explain to a user why >> an application "hangs" on close. However they do understand that it >> may hang on open. >> >>>> From my experience a usefull implementation for close is a >>>> timeout >>>> based synchronous close with a rather small timeout. If the close >>>> "works" (ie no kernel/driver problem preventing it's execution) >>>> wait >>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>> return from the call. The trend for the kernel implementation of >>>> close is clearly "abort" r/w operations. It used to be wait for >>>> the >>>> end of r/w operations. >>> >>> Well, serial data can flow slowly compared to what a program can >>> generate. So, >>> it should be possible for an application to open a port at 300baud, >>> send some >>> large amount of data and block on the close, waiting for the send >>> to complete. >> >> This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsend data on close, abort reads and release >> the system resource as soon as possible. >> >>>> From a user perspective, closing a resource means "I lost all >>>> interest in you". In the case where the (synchronous) close is >>>> immediate that is no problem. However in the case where it is not, >>>> this creates big problems. The application by itself has >>>> basicly no >>>> means of dealing with a blocking close. As the user has lost >>>> interest >>>> in the port he will not understand any kind of dialog regarding an >>>> already closed port, he might have even decided to close the >>>> application and see that it "hangs" on close. >>> >>> It is possible for a java application to do >>> >>> Thread th = new Thread() { >>> public void run() { >>> try { >>> port.close(); >>> } catch( Exception ex ) { >>> log.log( Level.WARNING, ex.toString(), ex ); >>> } >>> } >>> }; >>> th.setDaemon( true ); >>> th.run(); >>> >> >> 1st problem) This returns immediately (even in the case where close >> does not block and returns within a few seconds). Hence the >> application has no idea of the progress of the close, it has to join >> the close thread or even have a callback interface to get status >> updates. This is what I often do, but it is neither elegant nor >> simple. >> 2nd problem) The application has to keep track of ports which are in >> the state of beeing closed if it wants to reuse/reopen the same ports >> (race conditions). >> 3rd problem) From what I have seen the java "process" will not >> unwind/ >> return if a java thread hangs in a kernel call (daemon or not). That >> problem most likely affects my prefered solution as well, but the >> above code "suggests" otherwise. >> >>> ...implementation detail about networking. Serial ports don't have >>> the same >>> negociated close. Close progresses, unimpeded, when the write >>> buffer is empty. >> >> In my experience the kernel level close may block if the USB driver >> is trapped in a weird situation (ie a client device not reacting). It >> may block even if no data remains to be send, I consider this a >> kernel/driver/device bug - but unfortunately changes to the kernel/ >> driver/device are often impossible. >> >>> If remote flow control is asserted, there is no negociation for >>> relief. This >>> is why it seems interesting, to let the close happen >>> asynchronously. In single >>> threaded programming environments, it becomes very convenient to do >>> this, but I >>> don't think it's a correct behavior. When serial hardware/software >>> is broken, >>> and the flowcontrol never subsides, the application can hang >>> forever. >> >> I have seen cases where unplugging a USB device at the "right moment" >> or a buggy device that stops responding leads to a close blocking for >> hours. This is nothing the application can influence. Arguing, that >> an application should be allowed to hang if the OS/driver/hardware >> has bugs works in theory but not in (my) practice. I have seen cases, >> where (only) quitting the Java VM will unwind a hanging kernel close. >> I can not explain this behaviour, but I can reproduce it with a buggy >> USB device. >> >> Best regards, >> Joachim >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Sep 27 07:48:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 27 Sep 2006 09:48:04 -0400 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: Hi All, I think Joachim might be correct. Flush and close may not appropriate to combine into the implementation. The semantics of close are already complex. If you close and get a PortInUseException, then you simply will not be able to close. Other exceptions that might occur include an IOException. Would it make sense to have these exceptions appear in the specification? Are there other exceptions that we might need? Thanks! - DL >I strongly opt to NOT call OutputStream.flush() in the implementation? >of Port.close(). We COULD call it in OutputStream.close() even though? >I would argue not to do it to motivate clean coding. > >Flush has no timeout sematics. Calling OutputStream.flush() in? >Port.close() effectively kills the only abort mechanism that exist. > >I am aware, that many Java stream implementations call flush in the? >close. Especially the higher level ones. This is all nice and handy? >until you see the results in the real world. Missing flush calls and? >flushes at the wrong moment are the source of 50% of performance? >problems in network applications. I think it's a very bad idea? >because relying on flush to get data delivered doesn't work anyway.? >In most out of lab scenarios only one assumption holds: If the other? >side (receiving application, not network stack) hasn't checked and? >confirmed it, it didn't arrive. > >In my opinion a SerialPort should react like a Socket. This is the? >closest widely known equivalent existing in the Java standard? >distribution. Calling close on a TCP-Socket (not the Outputstream of? >the Socket!) closes this socket immediately without calling flush. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: > >> Hi All, >> Joachim suggests that: >> "This is the one point where I really disagree. Port.close() should >> never be used in the meaning of OutputStream.flush(). Port.close() is >> the only abort mechanism available. The native implementation should >> be free to throw away unsent data on close, abort reads and release >> the system resource as soon as possible." >> >> This may be a good point. >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> OutputStream.html#close() >> Says that: >> Closes this output stream and releases any system >> resources associated with this stream. The >> general contract of close is that it closes the >> output stream. A closed stream cannot perform >> output operations and cannot be reopened. >> >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an? >> implementation, >> implicitly. They are also often (but not always) left out of the? >> specification! >> >> I would say that is not an optimal treatment and that we can do? >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() >> Shows no flush close. But the code at the top of the document shows: >> FileOutputStream fos = new FileOutputStream("t.tmp"); >> ObjectOutputStream oos = new ObjectOutputStream(fos); >> >> oos.writeInt(12345); >> oos.writeObject("Today"); >> oos.writeObject(new Date()); >> >> oos.close(); >> >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? >> >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the? >> implementation. >> >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in > > the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. >> >> There is no consistency on close implementations in the IO package. > > Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. The? >> methods in >> * this class can be called after the stream has been closed? >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } >> >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream >> * calls its flush method, and then calls the >> * close method of its underlying output stream. >> * >> * @exception IOException if an I/O error occurs. >> * @see java.io.FilterOutputStream#flush() >> * @see java.io.FilterOutputStream#out >> */ >> public void close() throws IOException { >> try { >> flush(); >> } catch (IOException ignored) { >> } >> out.close(); >> } >> >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. >> >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException >> >> At present, we have: >> public interface CommPortInterface { >> /** >> * @return the name of this port. >> */ >> String getName(); >> >> /** >> * @return a string representation of this port. >> */ >> String toString(); >> >> /** >> * Closes this communications port. Further methods on this? >> object will >> * throw IllegalStateException. All PortOwnershipListeners? >> will be >> * notified of this change of ownership. >> */ >> void close(); >> } >> >> >> Now, RXTXPort shows: >> public synchronized void close() { >> >> Is this consistent with the present specification, and if not, what? >> should >> we do? >> >> Thanks! >> - Doug >> >> >>> I always appreciate a discussion based on good arguments;-) >>> >>> I know that Linus T. has argued several times that non-blocking close >>> does not work. However in those cases where it does not work on the >>> kernel level it can not be made to work on the application level >>> neither. In my experience it is impossible to explain to a user why >>> an application "hangs" on close. However they do understand that it >>> may hang on open. >>> >>>>> From my experience a usefull implementation for close is a? >>>>> timeout >>>>> based synchronous close with a rather small timeout. If the close >>>>> "works" (ie no kernel/driver problem preventing it's execution)? >>>>> wait >>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>> return from the call. The trend for the kernel implementation of >>>>> close is clearly "abort" r/w operations. It used to be wait for? >>>>> the >>>>> end of r/w operations. >>>> >>>> Well, serial data can flow slowly compared to what a program can >>>> generate. So, >>>> it should be possible for an application to open a port at 300baud, >>>> send some >>>> large amount of data and block on the close, waiting for the send >>>> to complete. >>> >>> This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close() is >>> the only abort mechanism available. The native implementation should >>> be free to throw away unsend data on close, abort reads and release >>> the system resource as soon as possible. >>> >>>>> From a user perspective, closing a resource means "I lost all >>>>> interest in you". In the case where the (synchronous) close is >>>>> immediate that is no problem. However in the case where it is not, >>>>> this creates big problems. The application by itself has > >>>> basicly no >>>>> means of dealing with a blocking close. As the user has lost? >>>>> interest >>>>> in the port he will not understand any kind of dialog regarding an >>>>> already closed port, he might have even decided to close the > >>>> application and see that it "hangs" on close. >>>> >>>> It is possible for a java application to do >>>> >>>> Thread th = new Thread() { >>>> public void run() { >>>> try { >>>> port.close(); >>>> } catch( Exception ex ) { >>>> log.log( Level.WARNING, ex.toString(), ex ); >>>> } >>>> } >>>> }; >>>> th.setDaemon( true ); >>>> th.run(); >>>> >>> >>> 1st problem) This returns immediately (even in the case where close >>> does not block and returns within a few seconds). Hence the >>> application has no idea of the progress of the close, it has to join >>> the close thread or even have a callback interface to get status >>> updates. This is what I often do, but it is neither elegant nor? >>> simple. >>> 2nd problem) The application has to keep track of ports which are in >>> the state of beeing closed if it wants to reuse/reopen the same ports >>> (race conditions). >>> 3rd problem) From what I have seen the java "process" will not? >>> unwind/ >>> return if a java thread hangs in a kernel call (daemon or not). That >>> problem most likely affects my prefered solution as well, but the >>> above code "suggests" otherwise. >>> >>>> ...implementation detail about networking. Serial ports don't have >>>> the same >>>> negociated close. Close progresses, unimpeded, when the write >>>> buffer is empty. >>> >>> In my experience the kernel level close may block if the USB driver >>> is trapped in a weird situation (ie a client device not reacting). It >>> may block even if no data remains to be send, I consider this a >>> kernel/driver/device bug - but unfortunately changes to the kernel/ >>> driver/device are often impossible. >>> >>>> If remote flow control is asserted, there is no negociation for >>>> relief. This >>>> is why it seems interesting, to let the close happen >>>> asynchronously. In single >>>> threaded programming environments, it becomes very convenient to do >>>> this, but I >>>> don't think it's a correct behavior. When serial hardware/software >>>> is broken, >>>> and the flowcontrol never subsides, the application can hang? >>>> forever. >>> >>> I have seen cases where unplugging a USB device at the "right moment" >>> or a buggy device that stops responding leads to a close blocking for >>> hours. This is nothing the application can influence. Arguing, that >>> an application should be allowed to hang if the OS/driver/hardware >>> has bugs works in theory but not in (my) practice. I have seen cases, >>> where (only) quitting the Java VM will unwind a hanging kernel close. >>> I can not explain this behaviour, but I can reproduce it with a buggy >>> USB device. >>> >>> Best regards, >>> Joachim >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:10:09 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:10:09 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9451.5050806@cox.net> Dr. Douglas Lyon wrote: > This last bit, a closed stream cannot be reopened is really telling. > The roles of "flush" and "close" are often combined in an implementation, > implicitly. They are also often (but not always) left out of the specification! In the Unix I/O implementation, there is no flush call. Only write(2) and close(2) are documented to work for any particular fd returned from open(2). So, historically, close(2) has always had to include a wait for buffers to empty. In the early days of various Unix implementations, when every terminal was connected via a serial port, new serial hardware had new bugs. Close was always a problem. When we used modems to do UUCP, kermit etc, we always had to make sure and use appropriate ioctl(2) settings to manage the recognition of flow control at particular moments so as to avoid certain bugs and situations arrising from broken hardware and software. > I would say that is not an optimal treatment and that we can do better. > > For example: > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#close() ... > There is no flush in the example! Technically, according to the spec, > this should write out NOTHING! But it DOES WORK!! Why? As noted above, this, historically has had to work because there is not always an equivalent flush() at the OS level. > But from the source code of the ObjectOutputStream.java, I see: > public void close() throws IOException { > flush(); > clear(); > bout.close(); > } > So, the flush is not in the specification, but it is in the implementation. The buffering mechanism available in Java are a design paradigm meant to allow functionality similar to what stdio(3) provides to the Unix programmer. The issue is that various I/O streams are bi-directional, and it is necessary then to flush the output before reading more input, in order for these conversational exchanges to work. In raw Unix/C I/O with read(2) and write(2), there is an implicit flush, because there is no other mechanism available. For certain types of devices, there are ioctl() operations to do line mode buffering. For some types of I/O, such as to a Unix PIPE, you are dealing with a one-way based I/O subsystem that may perform buffering in particular circumstances. This is one of the reasons why Berkeley Unix folks created Unix-Domain Sockets. They allow conversational I/O to occur between processes without interfering buffering. > As a Java programmer, I have gotten used to making the assumption > that flush and close are combined and that the flush is implicit in > the close. > > I am now starting to question my assumption. Whatever we decide, > it should probably be explicit in the specification. Don't question your assumption. close() must include flush(), in Java to be correct. There is no ifs, ands, or buts about it. > There is no consistency on close implementations in the IO package. > Check out the close on the ByteArrayOutputStream: > /** > * Closing a ByteArrayOutputStream has no effect. The methods in > * this class can be called after the stream has been closed without > * generating an IOException. > *

> * > */ > public void close() throws IOException { > } This is a bad example, because the write() operation extends the array automatically, and makes the implementation meet the requirements all the APIs represented in the class. If write did not extend the array, the toByteArray() and close() would have to do that eventually. The implementation is less complex because it does the work early rather than defering it to later and thus requiring a check to see if the flush activity had been done. > Now check the FilterOutputStream: > * The close method of FilterOutputStream > Perhaps something like the FilterOutputStream makes sense for us. But > should we be ignoring exceptions on close? Perhaps we can close by > trying to flush, then release the resource in a finally statement and > STILL throw an exception to the caller. FilterOutputStream is just a delegating OutputStream that allows the write() or other methods to be overridden so that you can replace certain logic to create filtered results. So, it has to call flush, close and everything else to meet the contract of the I/O apis. > We may need a different exception for flush than for the internal > close, to facilitate debugging. Thus > public void close() throws IOException, PortInUseException The correct way to do this is to subclass an IOException to create PortInUseException. Some applications might deal with it explicitly if they allow multiple ports to be used, such as application using a bank of modems that just needs one that's not in use. Others, might just let this exception go up to a higher level to tell other code, or the user of the application that the selected port is not available. At the application level, this exception can be used to create small delays and retries while waiting for close to settle (if close is done asynchronously). Gregg Wonderly From ajmas at sympatico.ca Wed Sep 27 09:29:40 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 27 Sep 2006 11:29:40 -0400 Subject: [Rxtx] port in use exception Message-ID: <20060927152940.DDDT1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Gregg Wonderly wrote: > > Well, serial data can flow slowly compared to what a program > can generate. So, it should be possible for an application to > open a port at 300baud, send some large amount of data and block > on the close, waiting for the send to complete. > Just thinking out loud: should the write() return before the underlying OS written everything or wait until the the system has finished sending all the data? What is the philosophy that is used in the java.io classes with regards to this? Maintaining a certain consistency with the approach used in java.io would avoid unexpected surprises for developers used to a certain behaviour. Andre From joachim at buechse.de Wed Sep 27 09:33:00 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 17:33:00 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451A9451.5050806@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <451A9451.5050806@cox.net> Message-ID: <80FB2F5B-EA54-4D0C-8B69-0B1AD0957C05@buechse.de> man tcdrain On 27.09.2006, at 17:10, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> This last bit, a closed stream cannot be reopened is really telling. >> The roles of "flush" and "close" are often combined in an >> implementation, >> implicitly. They are also often (but not always) left out of the >> specification! > > In the Unix I/O implementation, there is no flush call. Only write > (2) and > close(2) are documented to work for any particular fd returned from > open(2). > So, historically, close(2) has always had to include a wait for > buffers to > empty. In the early days of various Unix implementations, when > every terminal > was connected via a serial port, new serial hardware had new bugs. > Close was > always a problem. When we used modems to do UUCP, kermit etc, we > always had to > make sure and use appropriate ioctl(2) settings to manage the > recognition of > flow control at particular moments so as to avoid certain bugs and > situations > arrising from broken hardware and software. > >> I would say that is not an optimal treatment and that we can do >> better. >> >> For example: >> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >> ObjectOutputStream.html#close() > ... >> There is no flush in the example! Technically, according to the spec, >> this should write out NOTHING! But it DOES WORK!! Why? > > As noted above, this, historically has had to work because there is > not always > an equivalent flush() at the OS level. > >> But from the source code of the ObjectOutputStream.java, I see: >> public void close() throws IOException { >> flush(); >> clear(); >> bout.close(); >> } >> So, the flush is not in the specification, but it is in the >> implementation. > > The buffering mechanism available in Java are a design paradigm > meant to allow > functionality similar to what stdio(3) provides to the Unix > programmer. The > issue is that various I/O streams are bi-directional, and it is > necessary then > to flush the output before reading more input, in order for these > conversational > exchanges to work. In raw Unix/C I/O with read(2) and write(2), > there is an > implicit flush, because there is no other mechanism available. For > certain > types of devices, there are ioctl() operations to do line mode > buffering. For > some types of I/O, such as to a Unix PIPE, you are dealing with a > one-way based > I/O subsystem that may perform buffering in particular > circumstances. This is > one of the reasons why Berkeley Unix folks created Unix-Domain > Sockets. They > allow conversational I/O to occur between processes without > interfering buffering. > >> As a Java programmer, I have gotten used to making the assumption >> that flush and close are combined and that the flush is implicit in >> the close. >> >> I am now starting to question my assumption. Whatever we decide, >> it should probably be explicit in the specification. > > Don't question your assumption. close() must include flush(), in > Java to be > correct. There is no ifs, ands, or buts about it. > >> There is no consistency on close implementations in the IO package. >> Check out the close on the ByteArrayOutputStream: >> /** >> * Closing a ByteArrayOutputStream has no effect. >> The methods in >> * this class can be called after the stream has been closed >> without >> * generating an IOException. >> *

>> * >> */ >> public void close() throws IOException { >> } > > This is a bad example, because the write() operation extends the array > automatically, and makes the implementation meet the requirements > all the APIs > represented in the class. If write did not extend the array, the > toByteArray() > and close() would have to do that eventually. The implementation > is less > complex because it does the work early rather than defering it to > later and thus > requiring a check to see if the flush activity had been done. > >> Now check the FilterOutputStream: >> * The close method of FilterOutputStream > >> Perhaps something like the FilterOutputStream makes sense for us. But >> should we be ignoring exceptions on close? Perhaps we can close by >> trying to flush, then release the resource in a finally statement and >> STILL throw an exception to the caller. > > FilterOutputStream is just a delegating OutputStream that allows > the write() or > other methods to be overridden so that you can replace certain > logic to create > filtered results. So, it has to call flush, close and everything > else to meet > the contract of the I/O apis. > >> We may need a different exception for flush than for the internal >> close, to facilitate debugging. Thus >> public void close() throws IOException, PortInUseException > > The correct way to do this is to subclass an IOException to create > PortInUseException. Some applications might deal with it > explicitly if they > allow multiple ports to be used, such as application using a bank > of modems that > just needs one that's not in use. Others, might just let this > exception go up > to a higher level to tell other code, or the user of the > application that the > selected port is not available. At the application level, this > exception can be > used to create small delays and retries while waiting for close to > settle (if > close is done asynchronously). > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Wed Sep 27 09:52:28 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 10:52:28 -0500 Subject: [Rxtx] port in use exception In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> Message-ID: <451A9E3C.9030803@cox.net> Joachim Buechse wrote: > I always appreciate a discussion based on good arguments;-) > > I know that Linus T. has argued several times that non-blocking close > does not work. However in those cases where it does not work on the > kernel level it can not be made to work on the application level > neither. In my experience it is impossible to explain to a user why > an application "hangs" on close. However they do understand that it > may hang on open. I think part of the issue is whether there is any real value added by waiting till (re)open to tell the user that their serial port is hung, or to do that by blocking on close. >>Well, serial data can flow slowly compared to what a program can >>generate. So, >>it should be possible for an application to open a port at 300baud, >>send some >>large amount of data and block on the close, waiting for the send >>to complete. > > This is the one point where I really disagree. Port.close() should > never be used in the meaning of OutputStream.flush(). Port.close() is > the only abort mechanism available. The native implementation should > be free to throw away unsend data on close, abort reads and release > the system resource as soon as possible. This is not part of the API contract, and not what developers or users would expect. If there is a need to exit prematurely, and the application is dealing with a slow data rate, it can use queuing designs to minimize the amount of data that is being written for each write call, based on baud rate, to create a suitably short delay. boolean done; public synchronized void stopNow() { done = true; } public void writeBuffer( byte[]buf ) { int i = 0; int remain = buf.length; int cnt = baud/10; while( remain > 0 ) { synchronized(this) { if( done ) throw new InterruptedException(remain+" bytes not written"); } int wrcnt = Math.min( cnt, remain ); int tot = write( buf, i, wrcnt ); if( tot <= 0 ) { throw new IOException( "write failed with: "+tot ); } remain -= tot; } } >>> From a user perspective, closing a resource means "I lost all >>>interest in you". In the case where the (synchronous) close is >>>immediate that is no problem. However in the case where it is not, >>>this creates big problems. The application by itself has basicly no >>>means of dealing with a blocking close. As the user has lost interest >>>in the port he will not understand any kind of dialog regarding an >>>already closed port, he might have even decided to close the >>>application and see that it "hangs" on close. >> >>It is possible for a java application to do >> >>Thread th = new Thread() { >> public void run() { >> try { >> port.close(); >> } catch( Exception ex ) { >> log.log( Level.WARNING, ex.toString(), ex ); >> } >> } >>}; >>th.setDaemon( true ); >>th.run(); >> > > 1st problem) This returns immediately (even in the case where close > does not block and returns within a few seconds). Hence the > application has no idea of the progress of the close, it has to join > the close thread or even have a callback interface to get status > updates. This is what I often do, but it is neither elegant nor simple. That's why I mentioned the use of a Future later. You can put this in a Future implementation and call Future.get() to indicate a rendevous with close(). A more interesting thing is to create a port redevous object that you use to say that a port is in use, and this allows multiple threads to wait to use it again. public class PortRendevous extends OutputStream implements Future { CommPortIdentifier port; boolean opened; boolean cancelled; public PortRendevous( CommPortIdentifier port ) { this.port = port; } public boolean cancel( boolean inter ) { synchronized( this ) { cancelled = true; if( inter ) { notifyAll(); } } return !opened; } public synchronized PortRendevous get( long val, TimeUnit unit) throws InterruptedException { cancelled = false; if( unit == TimeUnit.SECONDS ) val *= 1000; if( opened && !cancelled ) { try { wait( val ); } catch( InterruptedException ex ) { } } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public synchronized PortRendevous get() throws InterruptedException{ cancelled = false; while( opened && !cancelled ) { wait(); } if( cancelled ) { throw new InterruptedException( "get "+port+" cancelled"); } return this; } public boolean isCancelled() { return cancelled; } public boolean isDone() { return opened; } public synchronized OutputStream open(String name, int timeout) throws IOException { // Wait for opened to be false get(); // Open the stream. OutputStream out = new FilteredOutputStream( port.open(name,timeout) ) { public void close() { super.close(); synchronized(PortRendevous.this) { opened = false; PortRendevous.this.notify(); } } }; // if no exceptions, we get to here, and so set opened=true opened = true; // return the output stream. return out; } } Somewhere in your application you then have. Mapports = new HashMap(); public OutputStream openPort( String name, int timeout ) { PortRendevous r = ports.get( name ); OutputStream os = r.open( name, timeout ); try { ... do something ... } finally { os.close(); } } Which will always block on the open, waiting for this thread to be the only user of the port. When the port is closed, the FilteredOutputStream.close() override will reset the opened status, and notify the waiters to let the next thread go. Because there is a future involved, a GUI component can track the status of the port open, ask isCancelled(), call cancel() etc to manage the activity of the threads accessing the port etc. All using exiting APIs that can be coded to create a different interface, without having to recode/change RXTX over time. > 2nd problem) The application has to keep track of ports which are in > the state of beeing closed if it wants to reuse/reopen the same ports > (race conditions). The Future implementation above takes care of that. > 3rd problem) From what I have seen the java "process" will not unwind/ > return if a java thread hangs in a kernel call (daemon or not). That > problem most likely affects my prefered solution as well, but the > above code "suggests" otherwise. The Java spec says that Daemon threads can not keep the JVM from exiting. >>...implementation detail about networking. Serial ports don't have >>the same >>negociated close. Close progresses, unimpeded, when the write >>buffer is empty. > > In my experience the kernel level close may block if the USB driver > is trapped in a weird situation (ie a client device not reacting). It > may block even if no data remains to be send, I consider this a > kernel/driver/device bug - but unfortunately changes to the kernel/ > driver/device are often impossible. These are driver bugs, like it or not. Covering them up, doesn't expedite the users relief of the problem, it only moves the experience to a later or different sequence of events. Production systems may need to work around these at the application layer. RXTX doesn't need to burden itself with anything related to these bugs as long as it provides a direct path to the kernel/OS functions, the user can create the same workarounds that you would in RXTX, and they inherit the associated mess instead of all users of RXTX having to be aware of certain behaviors that fall out of certain scenarios that were coded to work around bugs in the drivers. >> If remote flow control is asserted, there is no negociation for >>relief. This >>is why it seems interesting, to let the close happen >>asynchronously. In single >>threaded programming environments, it becomes very convenient to do >>this, but I >>don't think it's a correct behavior. When serial hardware/software >>is broken, >>and the flowcontrol never subsides, the application can hang forever. > > I have seen cases where unplugging a USB device at the "right moment" > or a buggy device that stops responding leads to a close blocking for > hours. This is nothing the application can influence. Arguing, that > an application should be allowed to hang if the OS/driver/hardware > has bugs works in theory but not in (my) practice. I have seen cases, > where (only) quitting the Java VM will unwind a hanging kernel close. > I can not explain this behaviour, but I can reproduce it with a buggy > USB device. I agree that this can be very frustrating. My main statement/argument is that the more software that RXTX puts between the user and the OS, the more the user has to live with in terms of undesired behaviour. The javax.comm API is simple in design, I believe, and that means that as a user, I have less to have to deal with in terms of unwanted or unneeded behaviour. Adding support for OS specific ioctls might be nice to support with a property based mechanism so that you could ask for the properties for a port, and then be able to see implementation specific options that you could change on a particular OS. But, building the API up with more methods that "do nothing" or return undependable results, will make it impossible to write dependable application code. If I can see the "properties", I can write code like List p = port.getPropertyNames(); if( p.contains(PortProperties.HW_TYPE).indexOf("buggy name") >= 0 ) { if( p.contains(PortProperties.ASYNC_CLOSE) == false ) { throw new IOException("Can't support port: "+port ); } } to tell the user that this combination is not going to work with my software. But, RXTX or the javax.comm API doesn't have to contain anything explicit about this issue. Gregg Wonderly From gergg at cox.net Wed Sep 27 10:01:31 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 27 Sep 2006 11:01:31 -0500 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <451AA05B.5090508@cox.net> Joachim Buechse wrote: > I strongly opt to NOT call OutputStream.flush() in the implementation > of Port.close(). We COULD call it in OutputStream.close() even though > I would argue not to do it to motivate clean coding. > > Flush has no timeout sematics. Calling OutputStream.flush() in > Port.close() effectively kills the only abort mechanism that exist. I'm not sure that there is a viable abort mechanism for serial ports, see below. > I am aware, that many Java stream implementations call flush in the > close. Especially the higher level ones. This is all nice and handy > until you see the results in the real world. Missing flush calls and > flushes at the wrong moment are the source of 50% of performance > problems in network applications. I think it's a very bad idea > because relying on flush to get data delivered doesn't work anyway. In java, by definition of the API, flush must result in all data being delivered to the OS. The OS might do additional buffering for some particular types of I/O streams, such as by previous PIPE discussion. But, technically, flush in java guarantees that no addional, pending I/O is buffered which was buffered before the call. > In most out of lab scenarios only one assumption holds: If the other > side (receiving application, not network stack) hasn't checked and > confirmed it, it didn't arrive. I think that there are numerous bad implementation of serial based software at the application level and at the driver level. It is NOT in any ones best interest to create hurestical software designs, at the standardized library level, which attempt to work around such problems. Others might develop such libraries and make them available as layers on top. But, I think its important to draw the line for a standardized library at a very simple level so that everyone can get exactly the implementation details they need without having to wade through things that are not adding value or needed functionality. > In my opinion a SerialPort should react like a Socket. This is the > closest widely known equivalent existing in the Java standard > distribution. Calling close on a TCP-Socket (not the Outputstream of > the Socket!) closes this socket immediately without calling flush. But we have no OS support for any such activity do we. Which Unix System calls would you make to affect a port close that guarantees that all pending I/O from other threads and all buffered I/O from all threads would be discarded, and the port closed? Dealing with all of that level of multithreading and resource contention is an application level thing. Gregg Wonderly From joachim at buechse.de Wed Sep 27 10:51:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 27 Sep 2006 18:51:53 +0200 Subject: [Rxtx] flush twice, it is a long way to the kitchen In-Reply-To: <451AA05B.5090508@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <451AA05B.5090508@cox.net> Message-ID: <43FB0F5B-C13C-4B72-BBA6-F394D8D6E7FD@buechse.de> It can not be guarenteed that all data is discarded, neither can it be guarenteed that any remaining data will be send. What is important, is the fact that closing a TCP-Socket on any OS I have seen and in Java will abort reads+writes. It makes little sense to model SerialPorts differently. Regarding your question: Writes from threads need to happen in a synchronized manner (via semophores, not synchronized methods). This is trivial as a semaphore is needed anyway to deny write after close on the Java level. Hence, at any time you will have a maximum of 1 thread blocking in write. A call to close first sets the "closed" flag/semaphore. No other threads will enter afterwards. If there is no blocking write, tcflush (POSIX) discards all unsend data. If there is a blocking write tcflush may block as well (on OS X) - so that doesn't help. While some OS kernels will not abort a blocking write when an asynchronous close happens, most will. The trend in newer versions is clearly to abort and unwind the write. If an OS blocks on fd.close until (an already blocking) write has finished sending all data, the fd.close should be delegated to the writing thread (or some other thread, in RXTX this could be the drain thread). This guarentees that Port.close() will return in a controled manner. The thread calling Port.close() can (and should) join if another thread is taking control of the actual closing. However in my opinion this join should have a relatively short timeout. Regards, Joachim On 27.09.2006, at 18:01, Gregg Wonderly wrote: > > But we have no OS support for any such activity do we. Which Unix > System calls > would you make to affect a port close that guarantees that all > pending I/O from > other threads and all buffered I/O from all threads would be > discarded, and the > port closed? Dealing with all of that level of multithreading and > resource > contention is an application level thing. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 17:24:33 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 17:24:33 -0600 (MDT) Subject: [Rxtx] CVS Server is back up Message-ID: I just noticed the CVS server is allowing logins again. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 27 17:41:05 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 27 Sep 2006 19:41:05 -0400 Subject: [Rxtx] CVS Server is back up In-Reply-To: References: Message-ID: <9C2BBDCA-E2E4-4E12-B5A5-EF237625DEA3@mediaspansoftware.com> Yup, thanks Trent. On Sep 27, 2006, at 7:24 PM, Trent Jarvi wrote: > > I just noticed the CVS server is allowing logins again. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Sep 27 18:08:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 27 Sep 2006 18:08:37 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <4516796B.14342.84C784@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com> Message-ID: On Sun, 24 Sep 2006, Knute Johnson wrote: > So I've redone my tests and specifically set the receive timeout and > receive threshold states. > > receiveTimeoutDisabled() and receiveThresholdDisabled() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.disableReceiveTimeout(); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: false > Started 12:06:48 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > 12:06:48 -1 > > Note that it returns very quickly from the read, many times per > second. This should block yes? > > Next is: > > enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > //import javax.comm.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > // both receive timeout and receive threshold disabled > sp.enableReceiveTimeout(Integer.MAX_VALUE); > sp.disableReceiveThreshold(); > > System.out.println("isReceiveThresholdEnabled: " + > sp.isReceiveThresholdEnabled()); > System.out.println("isReceiveTimeoutEnabled: " + > sp.isReceiveTimeoutEnabled()); > > InputStream is = sp.getInputStream(); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = is.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > isReceiveThresholdEnabled: false > isReceiveTimeoutEnabled: true > Started 12:09:11 > 12:09:51 -1 > 12:10:31 -1 > 12:11:11 -1 > 12:11:51 -1 > 12:12:32 -1 > 12:13:12 -1 > > Note the approximately 40 second timeout when Integer.MAX_VALUE > should yield about 562 hours. > > I did just find something interesting, a timeout setting of 65535 > gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be > close to an hour. > > Any suggestions of what to try next would be great. > > Thanks, > > Hi Knute This does appear to be a bug in the windows version. I did confirm th$ the timeout is not behaving as expected on w32. The Linux binaries do not display the problem. I guess many people do like I do in reality and implement their own timeout logic in their applications. I tried both int n = read() and read(byte[]). They both are returning right away which was not expected. The read() is obviously more of a problem returning 255/-1. There must be a mistake in the src/termios.c code. You might be able to get around the problem with your own code using the byte[] version of read with your own timeout logic. You could also read only when bytes are available (event). You can also check on the number of bytes available before the read. We will have to fix this bug for the next version of rxtx but thats not going to help with whats already there. If you spot the fix before me, please send it to the list. Otherwise I'll try to get to it as time allows on the weekends. -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Wed Sep 27 21:42:54 2006 From: knute at frazmtn.com (Knute Johnson) Date: Wed, 27 Sep 2006 20:42:54 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, Message-ID: <451AE24E.6638.B21F2E@knute.frazmtn.com> >Hi Knute > >This does appear to be a bug in the windows version. I did confirm th$ >the timeout is not behaving as expected on w32. The Linux binaries do not >display the problem. > >I guess many people do like I do in reality and implement their own >timeout logic in their applications. > >I tried both int n = read() and read(byte[]). They both are returning >right away which was not expected. The read() is obviously more of a >problem returning 255/-1. There must be a mistake in the src/termios.c >code. > >You might be able to get around the problem with your own code using the >byte[] version of read with your own timeout logic. You could also read >only when bytes are available (event). You can also check on the number >of bytes available before the read. > >We will have to fix this bug for the next version of rxtx but thats not >going to help with whats already there. If you spot the fix before me, >please send it to the list. Otherwise I'll try to get to it as time >allows on the weekends. > I've got a lot of running software in the wild that I was trying to convert to RXTX because of the unavailability of Sun's implementation. Unfortunately I really need the blocking capabilities as there is a lot of code to rewrite otherwise. I guess for now I'll just have to use Sun's code. I haven't done any UART programming in a lot of years but if you point me to the code I would be happy to take a look at it. Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Thu Sep 28 03:01:37 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 28 Sep 2006 05:01:37 -0400 Subject: [Rxtx] PortInUseException Message-ID: Hi All, What is the feeling of the group to Gregg's suggestion that PortInUseException be a subclass of the IOException class, rather than a subclass of the Exception class? Thanks! - Doug From joachim at buechse.de Thu Sep 28 00:56:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 08:56:57 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> Message-ID: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Well, I had a hard night because of this;-) At first sight Gregg and I seem to completely disagree on the matter of close. In reality I don't think that this is the case. I'm sure that Gregg has some practical experience that makes him advocate his standpoint, so do I. What are the facts: - FilterOutputStream (which is the Basis for BufferedOS, ObjectOS, etc) calls flush in close. - FileOutputStream makes no guarentees about data beeing on disk. - HttpUrlConnection.OutputStream makes no guarentees about data beeing transmitted at all (it's just a buffer). It is quite likely that application programmers will wrap the Port.OutputStream in a BufferedOutputStream, Writer, etc. The library has no access to those objects which contain there own buffer. Calling Port.OutputStream.flush() in Port.close() has no usefull effect in those cases. I would hence suggest the following behaviour: 1) Port.OutputStream.close() MAY block until all data has been "sent". (in RXTX it will call Port.OS.flush()) 2) Port.OutputStream.flush() SHOULD block until all data has been "sent" (in RXTX it will call tcdrain). 3) Port.close() MUST NOT block. [Gregg, you'd probably want 1) to be SHOULD instead of MAY. I still think it's rather MAY then SHOULD, but SHOULD is OK for me as well.] [2) can not be stronger than SHOULD with some hardware] [The MUST NOT in 3) must be guarenteed even in the face of driver/ device errors.] To me, this behaviour seems the best match of what is in the API and what is expected by the programmer: - Guarenteed flush on close can be implemented by calling Port.OS.flush(), Port .OS.close(), Port.close() - Best effort flush on close can be implemented by calling Port.OS.close(), Port.close() - Best effort, non-blocking abort can be implemented with Port.close () (similar to HttpUrlConnection.disconnect()). With this implementation Port.finalise() MAY call Port.close() without risking to deadlock the virtual machines finalizer thread. [It is a whole new discussion if the garbage collector should be responsible to close leftover ports. For FileOutputStream this is the case, for HttpUrlConnections I have seen it, however I never checked where the Socket.close() is triggered. For the infamous animated GIF it is not the case (the GIF animator thread keeps them alive forever).] Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 27.09.2006, at 15:48, Dr. Douglas Lyon wrote: > Hi All, > I think Joachim might be correct. > Flush and close may not appropriate to combine into the > implementation. > > The semantics of close are already complex. If you > close and get a PortInUseException, then you simply will not > be able to close. Other exceptions that might occur include > an IOException. > > Would it make sense to have these exceptions appear in the > specification? Are there other exceptions that we might need? > Thanks! > - DL > >> I strongly opt to NOT call OutputStream.flush() in the implementation >> of Port.close(). We COULD call it in OutputStream.close() even though >> I would argue not to do it to motivate clean coding. >> >> Flush has no timeout sematics. Calling OutputStream.flush() in >> Port.close() effectively kills the only abort mechanism that exist. >> >> I am aware, that many Java stream implementations call flush in the >> close. Especially the higher level ones. This is all nice and handy >> until you see the results in the real world. Missing flush calls and >> flushes at the wrong moment are the source of 50% of performance >> problems in network applications. I think it's a very bad idea >> because relying on flush to get data delivered doesn't work anyway. >> In most out of lab scenarios only one assumption holds: If the other >> side (receiving application, not network stack) hasn't checked and >> confirmed it, it didn't arrive. >> >> In my opinion a SerialPort should react like a Socket. This is the >> closest widely known equivalent existing in the Java standard >> distribution. Calling close on a TCP-Socket (not the Outputstream of >> the Socket!) closes this socket immediately without calling flush. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 27.09.2006, at 14:22, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Joachim suggests that: >>> "This is the one point where I really disagree. Port.close() should >>> never be used in the meaning of OutputStream.flush(). Port.close >>> () is >>> the only abort mechanism available. The native implementation >>> should >>> be free to throw away unsent data on close, abort reads and release >>> the system resource as soon as possible." >>> >>> This may be a good point. >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> OutputStream.html#close() >>> Says that: >>> Closes this output stream and releases any system >>> resources associated with this stream. The >>> general contract of close is that it closes the >>> output stream. A closed stream cannot perform >>> output operations and cannot be reopened. >>> >>> This last bit, a closed stream cannot be reopened is really >>> telling. >>> The roles of "flush" and "close" are often combined in an >>> implementation, >>> implicitly. They are also often (but not always) left out of the >>> specification! >>> >>> I would say that is not an optimal treatment and that we can do >>> better. >>> >>> For example: >>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/ >>> ObjectOutputStream.html#close() >>> Shows no flush close. But the code at the top of the document >>> shows: >>> FileOutputStream fos = new FileOutputStream("t.tmp"); >>> ObjectOutputStream oos = new ObjectOutputStream(fos); >>> >>> oos.writeInt(12345); >>> oos.writeObject("Today"); >>> oos.writeObject(new Date()); >>> >>> oos.close(); >>> >>> There is no flush in the example! Technically, according to the >>> spec, >>> this should write out NOTHING! But it DOES WORK!! Why? >>> >>> But from the source code of the ObjectOutputStream.java, I see: >>> public void close() throws IOException { >>> flush(); >>> clear(); >>> bout.close(); >>> } >>> So, the flush is not in the specification, but it is in the >>> implementation. >>> >>> As a Java programmer, I have gotten used to making the assumption >>> that flush and close are combined and that the flush is implicit in >>> the close. >>> >>> I am now starting to question my assumption. Whatever we decide, >>> it should probably be explicit in the specification. >>> >>> There is no consistency on close implementations in the IO package. >>> Check out the close on the ByteArrayOutputStream: >>> /** >>> * Closing a ByteArrayOutputStream has no effect. The >>> methods in >>> * this class can be called after the stream has been closed >>> without >>> * generating an IOException. >>> *

>>> * >>> */ >>> public void close() throws IOException { >>> } >>> >>> Now check the FilterOutputStream: >>> * The close method of FilterOutputStream>> code> >>> * calls its flush method, and then calls the >>> * close method of its underlying output stream. >>> * >>> * @exception IOException if an I/O error occurs. >>> * @see java.io.FilterOutputStream#flush() >>> * @see java.io.FilterOutputStream#out >>> */ >>> public void close() throws IOException { >>> try { >>> flush(); >>> } catch (IOException ignored) { >>> } >>> out.close(); >>> } >>> >>> Perhaps something like the FilterOutputStream makes sense for >>> us. But >>> should we be ignoring exceptions on close? Perhaps we can close by >>> trying to flush, then release the resource in a finally >>> statement and >>> STILL throw an exception to the caller. >>> >>> We may need a different exception for flush than for the internal >>> close, to facilitate debugging. Thus >>> public void close() throws IOException, PortInUseException >>> >>> At present, we have: >>> public interface CommPortInterface { >>> /** >>> * @return the name of this port. >>> */ >>> String getName(); >>> >>> /** >>> * @return a string representation of this port. >>> */ >>> String toString(); >>> >>> /** >>> * Closes this communications port. Further methods on this >>> object will >>> * throw IllegalStateException. All PortOwnershipListeners >>> will be >>> * notified of this change of ownership. >>> */ >>> void close(); >>> } >>> >>> >>> Now, RXTXPort shows: >>> public synchronized void close() { >>> >>> Is this consistent with the present specification, and if not, what >>> should >>> we do? >>> >>> Thanks! >>> - Doug >>> >>> >>>> I always appreciate a discussion based on good arguments;-) >>>> >>>> I know that Linus T. has argued several times that non-blocking >>>> close >>>> does not work. However in those cases where it does not work on >>>> the >>>> kernel level it can not be made to work on the application level >>>> neither. In my experience it is impossible to explain to a user >>>> why >>>> an application "hangs" on close. However they do understand >>>> that it >>>> may hang on open. >>>> >>>>>> From my experience a usefull implementation for close is a >>>>>> timeout >>>>>> based synchronous close with a rather small timeout. If the >>>>>> close >>>>>> "works" (ie no kernel/driver problem preventing it's execution) >>>>>> wait >>>>>> until it has returned. If it blocks (ie more than 1..4 seconds) >>>>>> return from the call. The trend for the kernel >>>>>> implementation of >>>>>> close is clearly "abort" r/w operations. It used to be wait for >>>>>> the >>>>>> end of r/w operations. >>>>> >>>>> Well, serial data can flow slowly compared to what a program can >>>>> generate. So, >>>>> it should be possible for an application to open a port at >>>>> 300baud, >>>>> send some >>>>> large amount of data and block on the close, waiting for the >>>>> send >>>>> to complete. >>>> >>>> This is the one point where I really disagree. Port.close() should >>>> never be used in the meaning of OutputStream.flush(). Port.close >>>> () is >>>> the only abort mechanism available. The native implementation >>>> should >>>> be free to throw away unsend data on close, abort reads and >>>> release >>>> the system resource as soon as possible. >>>> >>>>>> From a user perspective, closing a resource means "I lost all >>>>>> interest in you". In the case where the (synchronous) close is >>>>>> immediate that is no problem. However in the case where it >>>>>> is not, >>>>>> this creates big problems. The application by itself has >>>>>> basicly no >>>>>> means of dealing with a blocking close. As the user has lost >>>>>> interest >>>>>> in the port he will not understand any kind of dialog >>>>>> regarding an >>>>>> already closed port, he might have even decided to close the >>>>>> application and see that it "hangs" on close. >>>>> >>>>> It is possible for a java application to do >>>>> >>>>> Thread th = new Thread() { >>>>> public void run() { >>>>> try { >>>>> port.close(); >>>>> } catch( Exception ex ) { >>>>> log.log( Level.WARNING, ex.toString(), ex ); >>>>> } >>>>> } >>>>> }; >>>>> th.setDaemon( true ); >>>>> th.run(); >>>>> >>>> >>>> 1st problem) This returns immediately (even in the case where >>>> close >>>> does not block and returns within a few seconds). Hence the >>>> application has no idea of the progress of the close, it has to >>>> join >>>> the close thread or even have a callback interface to get status >>>> updates. This is what I often do, but it is neither elegant nor >>>> simple. >>>> 2nd problem) The application has to keep track of ports which >>>> are in >>>> the state of beeing closed if it wants to reuse/reopen the same >>>> ports >>>> (race conditions). >>>> 3rd problem) From what I have seen the java "process" will not >>>> unwind/ >>>> return if a java thread hangs in a kernel call (daemon or not). >>>> That >>>> problem most likely affects my prefered solution as well, but the >>>> above code "suggests" otherwise. >>>> >>>>> ...implementation detail about networking. Serial ports >>>>> don't have >>>>> the same >>>>> negociated close. Close progresses, unimpeded, when the write >>>>> buffer is empty. >>>> >>>> In my experience the kernel level close may block if the USB >>>> driver >>>> is trapped in a weird situation (ie a client device not >>>> reacting). It >>>> may block even if no data remains to be send, I consider this a >>>> kernel/driver/device bug - but unfortunately changes to the >>>> kernel/ >>>> driver/device are often impossible. >>>> >>>>> If remote flow control is asserted, there is no negociation >>>>> for >>>>> relief. This >>>>> is why it seems interesting, to let the close happen >>>>> asynchronously. In single >>>>> threaded programming environments, it becomes very convenient >>>>> to do >>>>> this, but I >>>>> don't think it's a correct behavior. When serial hardware/ >>>>> software >>>>> is broken, >>>>> and the flowcontrol never subsides, the application can hang >>>>> forever. >>>> >>>> I have seen cases where unplugging a USB device at the "right >>>> moment" >>>> or a buggy device that stops responding leads to a close >>>> blocking for >>>> hours. This is nothing the application can influence. Arguing, >>>> that >>>> an application should be allowed to hang if the OS/driver/hardware >>>> has bugs works in theory but not in (my) practice. I have seen >>>> cases, >>>> where (only) quitting the Java VM will unwind a hanging kernel >>>> close. >>>> I can not explain this behaviour, but I can reproduce it with a >>>> buggy >>>> USB device. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 28 06:51:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 06:51:04 -0600 (MDT) Subject: [Rxtx] PortInUseException In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > > What is the feeling of the group to Gregg's suggestion > that PortInUseException be a subclass of the IOException > class, rather than a subclass of the Exception class? > Sounds fine. The only thing that comes to my mind is this may not only show up when calling open. There is the concept of port ownership in commapi with the capability of requesting ports from other owners. In the case of a PortInUseException potentially comming from trying to hijack a port rather than opening the port, an IOException may not be intuitive. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Sep 28 07:06:18 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 28 Sep 2006 07:06:18 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451AE24E.6638.B21F2E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, <4516796B.14342.84C784@knute.frazmtn.com>, <451AE24E.6638.B21F2E@knute.frazmtn.com> Message-ID: On Wed, 27 Sep 2006, Knute Johnson wrote: >> Hi Knute >> >> This does appear to be a bug in the windows version. I did confirm th$ >> the timeout is not behaving as expected on w32. The Linux binaries do not >> display the problem. >> >> I guess many people do like I do in reality and implement their own >> timeout logic in their applications. >> >> I tried both int n = read() and read(byte[]). They both are returning >> right away which was not expected. The read() is obviously more of a >> problem returning 255/-1. There must be a mistake in the src/termios.c >> code. >> >> You might be able to get around the problem with your own code using the >> byte[] version of read with your own timeout logic. You could also read >> only when bytes are available (event). You can also check on the number >> of bytes available before the read. >> >> We will have to fix this bug for the next version of rxtx but thats not >> going to help with whats already there. If you spot the fix before me, >> please send it to the list. Otherwise I'll try to get to it as time >> allows on the weekends. >> > > I've got a lot of running software in the wild that I was trying to > convert to RXTX because of the unavailability of Sun's > implementation. Unfortunately I really need the blocking > capabilities as there is a lot of code to rewrite otherwise. I guess > for now I'll just have to use Sun's code. > > I haven't done any UART programming in a lot of years but if you > point me to the code I would be happy to take a look at it. > > Thanks, > > Hi Knute I wish I had time to just jump in and find this bug. I'm sure I'll get to it but probably not as fast as you would like. The COMMTIMEOUTS structure in termios.c is what controls the kernel driver on top of the UART. The windows API calls are SetCommTimeouts and GetCommTimeouts. I suspect the bug is here: if ( s_termios->c_cc[VMIN] > 0 && vtime > 0 ) { /* read blocks forever on VMIN chars */ } else if ( s_termios->c_cc[VMIN] == 0 && vtime == 0 ) { /* read returns immediately */ timeouts.ReadIntervalTimeout = MAXDWORD; timeouts.ReadTotalTimeoutConstant = 0; timeouts.ReadTotalTimeoutMultiplier = 0; } I do not know what the bug is without further investigation. There is also the possibility that reads are not making the right assumptions in termios.c (serial_read()). As Linux is working, the bug is in the termios.c file. The code is going through the same path in SerialImp.c for w32 and linux. So once read is behaving like a Unix/Linux read, the rest will fall into place. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Thu Sep 28 07:55:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 08:55:11 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> Message-ID: <451BD43F.3000204@cox.net> Joachim Buechse wrote: > Well, > > I had a hard night because of this;-) At first sight Gregg and I seem > to completely disagree on the matter of close. In reality I don't > think that this is the case. I'm sure that Gregg has some practical > experience that makes him advocate his standpoint, so do I. > To me, this behaviour seems the best match of what is in the API and > what is expected by the programmer: I think that this represents a good position. In my previous postings, I was trying to stress some of the issues about the layering of the java.io classes on top of Port.OutputStream, which make Port completely unable to control all aspects of the I/O flushes, except when they might eventually come into the FilteredOutputStream or whatever wrapper is being used by Port to marry the user level to the OS level. Then important thing for me, is to make sure that if you are going to have Port.close be a kind of shutdown, that you understand the issue that the OS can't really provide a guarentee of interrupt of pending read/write activities. So, if you allow it to be non-blocking, and it returns successfully, but the blocking threads are not awakened and the I/O calls unwound, then the user hasn't really received any benefit from that call being non-blocking. Instead, they experience a non-blocking behavior which might suggest that everything is okay. I think that if you use some sort of timed wait for the writes to abort, you can provide some feedback to the user on the Port.close() call. But, I might just be thinking to deep about this. Gregg Wonderly From joachim at buechse.de Thu Sep 28 08:36:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 28 Sep 2006 16:36:16 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451BD43F.3000204@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> Message-ID: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Port.IS.read() and Port.OS.write() can be implemented to always unwind at Port.close() (even though this may require the use of non- blocking IO or even a separate thread depending on the features of the OS). Even if read+write don't unwind, I disagree that the user hasn't gained anything from a non-blocking close. A blocking Read or Write might have finished before the execution of Abort, or as a successfull result of Abort (read blocked by write on Palm OS), or as a non successfull result of Abort. I still have to see an application that reliably uses results obtained from a Context that was aborted. In GUI apps 99% of all cases Abort is the users way of saying: "Hey something went wrong that the application can't fix, I'll try a different port/server/etc." In server environments non-blocking abort can be used by a supervisor thread that controls the execution of worker threads. In production environments I have seen several cases where Oracle connections, TCP Sockets, Serial Ports, or any other "device" will simply block ignoring all attempts to shut it down. An application will always have to live with that, so a (rare;-) unwinding read/write must be acceptable. However a blocking close() will often have catastrophic results as people tend to call close() in finalize(). What I usually do in my GUI applications is the creation of async- workers: - A worker gets all data that needs to be send. - It returns the received data as an Object or byte[] (potentially via EventQueue.invokeLater()) - It can report progress via a small API (potentially via EventQueue.invokeLater()) - It has no access to application data structures. - It has an abort method. The abort method is non-blocking and makes sure that neither status nor result are returned "to the main application" after the abort function returned. This has been proven to be a very robust concept for UI driven applications. It confines synchronisation to a very small part of the application, it's reasonably simple to understand and implement. Unless your data communication is highly "interactive" with the application data structures it works like a charm and simplifies the application design considerably. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.09.2006, at 15:55, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Well, >> >> I had a hard night because of this;-) At first sight Gregg and I seem >> to completely disagree on the matter of close. In reality I don't >> think that this is the case. I'm sure that Gregg has some practical >> experience that makes him advocate his standpoint, so do I. > >> To me, this behaviour seems the best match of what is in the API and >> what is expected by the programmer: > > I think that this represents a good position. In my previous > postings, I was > trying to stress some of the issues about the layering of the > java.io classes on > top of Port.OutputStream, which make Port completely unable to > control all > aspects of the I/O flushes, except when they might eventually come > into the > FilteredOutputStream or whatever wrapper is being used by Port to > marry the user > level to the OS level. Then important thing for me, is to make > sure that if you > are going to have Port.close be a kind of shutdown, that you > understand the > issue that the OS can't really provide a guarentee of interrupt of > pending > read/write activities. So, if you allow it to be non-blocking, and > it returns > successfully, but the blocking threads are not awakened and the I/O > calls > unwound, then the user hasn't really received any benefit from that > call being > non-blocking. Instead, they experience a non-blocking behavior > which might > suggest that everything is okay. > > I think that if you use some sort of timed wait for the writes to > abort, you can > provide some feedback to the user on the Port.close() call. But, I > might just > be thinking to deep about this. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Thu Sep 28 19:14:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 28 Sep 2006 20:14:00 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> Message-ID: <451C7358.8020701@cox.net> Joachim Buechse wrote: > Port.IS.read() and Port.OS.write() can be implemented to always > unwind at Port.close() (even though this may require the use of non- > blocking IO or even a separate thread depending on the features of > the OS). What I worry the most about is that your implementation on different OSes will behave so dramatically different that an application written to use the API will not work reliably. I.e. if different techniques at the source level are necessary to deal with OS and driver issues, because you chose to take advantage of some features on one OS that are not available on another. This is why I'd really like for the stuff that you are describing to not be the implementation, but to be a layer on top of the implementation that you or someone else can write/use to solve the problems that you have with the standard API. Look at the abstractions that Swing uses to mask the features and implementation details of multiple different graphics implementations. Only by not manifesting the OS/graphics behaviors into the APIs is it possible to write swing code that is portable. > Even if read+write don't unwind, I disagree that the user hasn't > gained anything from a non-blocking close. A blocking Read or Write > might have finished before the execution of Abort, or as a > successfull result of Abort (read blocked by write on Palm OS), or as > a non successfull result of Abort. I still have to see an application > that reliably uses results obtained from a Context that was aborted. I think we are talking past each other on this issue. You are talking about lots of different OS and driver issues. I'm trying to suggest that while those are interesting and valid concerns, direct treatment of them doesn't belong as a visible part, or behavior of the API and its operational characteristics. > In GUI apps 99% of all cases Abort is the users way of saying: "Hey > something went wrong that the application can't fix, I'll try a > different port/server/etc." Again, I think that Port.close not flushing is an okay concept, but I worry that concurrency will make that difficult to get exactly write in all cases. If there is the tiniest chance that it won't work, then an application can only provide access to that as one of the solutions. This makes the application much more complex. > In server environments non-blocking abort can be used by a supervisor > thread that controls the execution of worker threads. In production > environments I have seen several cases where Oracle connections, TCP > Sockets, Serial Ports, or any other "device" will simply block > ignoring all attempts to shut it down. An application will always > have to live with that, so a (rare;-) unwinding read/write must be > acceptable. However a blocking close() will often have catastrophic > results as people tend to call close() in finalize(). Again, OutputStream/InputStream.close() are going to be called, and shut rightly flush(). This means that anytime Port.close() is called, you have a 50% chance of needing to deal with unwinding a read/write already in the OS trying to shut things down. It is that contention and how it is handled that makes things really more difficult. So, if some thread or operational thread of execution is in the OS, and this keeps your port.close() from working, that will be a problem anyway. I guess I just don't see how adding all the complexity really solves the problem. I merely defers it, or moves the discovery or encounter with the issue to another place in the execution path. > What I usually do in my GUI applications is the creation of async- > workers: > > - A worker gets all data that needs to be send. > - It returns the received data as an Object or byte[] (potentially > via EventQueue.invokeLater()) > - It can report progress via a small API (potentially via > EventQueue.invokeLater()) > - It has no access to application data structures. > - It has an abort method. > > The abort method is non-blocking and makes sure that neither status > nor result are returned "to the main application" after the abort > function returned. > > This has been proven to be a very robust concept for UI driven > applications. It confines synchronisation to a very small part of the > application, it's reasonably simple to understand and implement. > Unless your data communication is highly "interactive" with the > application data structures it works like a charm and simplifies the > application design considerably. Using EventQueue is a convienent way to serialize operations so that you don't have to worry so much about resource contention. The java.util.concurrent stuff makes that kind of stuff accessible to the masses who might not be as familar with the issues of concurrent programming in Java. I appreciate that you find value in the ability to abort I/O operations. I use Java's async Socket.close() behavior all the time to halt separate threads that are reading/writing on a socket. It's very convienent. Gregg Wonderly From lyon at docjava.com Fri Sep 29 01:45:32 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 03:45:32 -0400 Subject: [Rxtx] to flush or not to flush, that is a question Message-ID: Hi All, Let me see if I can summarize the discussion on flushing so far: 1. Manual Flush: A close is just a close vs. 2. Automatic Flush: A close is a flush and then a close. On the one hand we can define a close for a serial port so that it closes the serial port and has no other role. If data has been left in the buffer, it will be lost unless a flush is done explicitly. While it is the case that this would seem to speed up the close method, some might argue that the loss of data is not good software engineering, thus impacting system reliability. People will use: sp.flush(); sp.close(); as a serial port idiom, if close does not automatically flush. If flush does not precede close, the possible loss of data should be taken into account at the programmers' level, or it is a semantic error. Others argue that a slow serial line will delay the delivery of data for so long that the close will appear stalled. Corner-point: The emperor has no close. Suppose the serial device gets all stuffed up and data cannot be delivered. In such a case, the close will never finish with the flush and the serial port will never be released. In such a case, other programs (and users) who need the resource will be unable to access it. Digression: once I went to a wedding on a boat where the head was all stuffed up. Users were unable to flush and the OutputStream never closed... :( A serial port is a system wide resource for which many applications may contend. Once it is assigned to a process, in theory, no other application may usurp it. Wont deadlock from unreleased resources impact system reliability? So, on the one hand we adversely impact system reliability with increased chance of deadlock, or adversely impact system reliability with increased chance of data loss. To address the corner-point, the flush might need a time-out. Perhaps this can be computed as a function of the serial port data rate and the amount of data in the buffer. Please let me know if I am missing something. Thanks! - Doug From joachim at buechse.de Fri Sep 29 03:13:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:13:41 +0200 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <451C7358.8020701@cox.net> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> Message-ID: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Gregg, I also think that we are talking past each other, let me try to restate what I want to say. If javax.comm.Port.close() tries to flush, no application layer above can implement abort on any platform. Port.close() can not guarentee that all data will be send, hence it should not even try. Port.close () should have the semantic of abort. It should be non-blocking (per API definition) as this simplifies application logic and finalization. What I suggest will behave exactly identical on all OSs: - javax.comm.Port.close() returns within a guarenteed small delay. - any succeding IS.read/OS.write will throw an IOException - no more native read/write will be scheduled - the resource will be released as soon as any already scheduled native read/write has returned (no delay can be guarenteed) It is up to the library implementation to guarentee this behaviour (and it can be done easily). Some OSs can not unwind native read/ write calls on abort - that is okay and should not worry a programmer using javax.comm. It is up to the javax.comm API to define if read/write unwinding happens on the Java thread level or not. Unwinding on the Java level can always be implemented with handover, this is nice to have but I am NOT demanding that at all. If the definition is "IS.read/OS.write do not unwind within a guarenteed delay after Port.close()" that's perfectly ok with me. As I tried to explain, this issue shouldn't be of big interest to most programmers as the weaker definition can be catered for quite easily on the application level but the behaviour should be defined in the API, so that library implementors and programmers don't duplicate their efforts. If you do not agree with the above, maybe you can provide a concrete example where it will create problems or make things overly/more complicated. Just to be very clear: I am not suggesting to add my "workers" abstraction to the javax.comm API. This was just an example of how non-unwinding read/write can be handled on the application level. Best regards, Joachim BTW: Socket and HttpUrlConnection are much better examples then Swing where java code actually works cross-platform. On 29.09.2006, at 03:14, Gregg Wonderly wrote: > Joachim Buechse wrote: >> Port.IS.read() and Port.OS.write() can be implemented to always >> unwind at Port.close() (even though this may require the use of non- >> blocking IO or even a separate thread depending on the features of >> the OS). > > What I worry the most about is that your implementation on > different OSes will > behave so dramatically different that an application written to use > the API will > not work reliably. I.e. if different techniques at the source > level are > necessary to deal with OS and driver issues, because you chose to > take advantage > of some features on one OS that are not available on another. > > This is why I'd really like for the stuff that you are describing > to not be the > implementation, but to be a layer on top of the implementation that > you or > someone else can write/use to solve the problems that you have with > the standard > API. > > Look at the abstractions that Swing uses to mask the features and > implementation > details of multiple different graphics implementations. Only by > not manifesting > the OS/graphics behaviors into the APIs is it possible to write > swing code that > is portable. > >> Even if read+write don't unwind, I disagree that the user hasn't >> gained anything from a non-blocking close. A blocking Read or Write >> might have finished before the execution of Abort, or as a >> successfull result of Abort (read blocked by write on Palm OS), or as >> a non successfull result of Abort. I still have to see an application >> that reliably uses results obtained from a Context that was aborted. > > I think we are talking past each other on this issue. You are > talking about > lots of different OS and driver issues. I'm trying to suggest that > while those > are interesting and valid concerns, direct treatment of them > doesn't belong as a > visible part, or behavior of the API and its operational > characteristics. From joachim at buechse.de Fri Sep 29 03:38:44 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 11:38:44 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: My arguing must have been horribly unclear: All I want is a distinction between Port.close() and Port.OutputStream.close(). - Port.close() MUST NOT block (which means it can not flush). - Port.OutputStream.close() MAY flush. Regarding you question: I think that OutputStream.flush() should NOT timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an exception if Port.close() is called. Turning the MAY into a "MUST" can complicate the API implementation (some OSs will not unwind a native tcdrain call and hence a handover mechanism / background thread has to be used). In RXTX this thread already exists so the RXTX implementation would not get systematicly more complicated. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and > the > amount of data in the buffer. > > Please let me know if I am missing something. > > Thanks! > - Doug > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Fri Sep 29 05:17:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 07:17:04 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi Joachim, As I understand it, if close blocks the invokers' thread of execution it does not prevent another thread from calling System.exit(0). So, if we, as programmers, deem it OK to build our own time-out for the close mechanism, I think this should be possible, right? On the other hand, if close never executes, the danger of a serial port deadlock condition would seem to grow, right? In the typical case, exiting before the close has completed only defers the problem that the serial port cannot close, right? Even worse, how will I know (inside of my own program) when the close has completed? Will I need a call-back mechanism (Listener) in order to be notified of this? Thanks! - Doug >My arguing must have been horribly unclear: > >All I want is a distinction between Port.close() and? >Port.OutputStream.close(). >- Port.close() MUST NOT block (which means it can not flush). >- Port.OutputStream.close() MAY flush. > >Regarding you question: I think that OutputStream.flush() should NOT? >timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an? >exception if Port.close() is called. Turning the MAY into a "MUST"? >can complicate the API implementation (some OSs will not unwind a? >native tcdrain call and hence a handover mechanism / background? >thread has to be used). In RXTX this thread already exists so the? >RXTX implementation would not get systematicly more complicated. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and? >> the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> >> Thanks! >> - Doug >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Fri Sep 29 06:02:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 29 Sep 2006 14:02:11 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hello Doug, - A blocked thread does stop you calling System.exit(). - System.exit() does not execute any garbage collection or java finalization, so file handles etc. may still be open. They are however cleaned up when the unix JVM process exits/uwinds. - A thread blocked in a kernel call will stop the java process from unwinding/exiting. The process is transformed into a zombie and holds on to it's resources until it can unwind. 1) You may spawn a thread to call close (time-out mechanism), however you should not if this is inside a finalize call. 2) If the unix fd close never executes, you have a stale filehandle. However I never suggested it should not be called! 3) "Exiting" the Java VM before unix fd close returns changes nothing. Returning from Port.close() in the case that it can not complete defers the unresolvable problem to the next person trying to use the unusable port. All other ports and the VM in general (GC, Finalization) should still work fine. 4) You don't know when the kernel has finished cleaning up after a unix fd close on a blocking fd. This is the same for IP sockets and files in Java. As no usefull information can be extracted from this, I don't think it's an issue. There are two informations you may want to know: Q: When has all data been sent on a port? A: When Port.OutputStream.flush() returns, which may be called from Port.OutputStream.close() Q: When can I reuse/open a Port? A: When Port.isCurrentlyOwned() returns false (CommPortOwnershipListener signals it) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > Hi Joachim, > > As I understand it, > if close blocks the invokers' thread of execution > it does not prevent another thread from calling > System.exit(0). > So, if we, as programmers, deem it OK to build our > own time-out for the close mechanism, I think this should be > possible, right? > > On the other hand, if close never executes, the danger of > a serial port deadlock condition would seem to grow, right? > > In the typical case, exiting before the close has completed > only defers the problem that the serial port cannot close, right? > > Even worse, how will I know (inside of my own program) when > the close has completed? Will I need a call-back mechanism > (Listener) in > order to be notified of this? > > Thanks! > - Doug > > >> My arguing must have been horribly unclear: >> >> All I want is a distinction between Port.close() and >> Port.OutputStream.close(). >> - Port.close() MUST NOT block (which means it can not flush). >> - Port.OutputStream.close() MAY flush. >> >> Regarding you question: I think that OutputStream.flush() should NOT >> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >> exception if Port.close() is called. Turning the MAY into a "MUST" >> can complicate the API implementation (some OSs will not unwind a >> native tcdrain call and hence a handover mechanism / background >> thread has to be used). In RXTX this thread already exists so the >> RXTX implementation would not get systematicly more complicated. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> Let me see if I can summarize the discussion on flushing so far: >>> >>> 1. Manual Flush: A close is just a close vs. >>> 2. Automatic Flush: A close is a flush and then a close. >>> >>> On the one hand we can define a close for a serial port >>> so that it closes the serial port and has no other role. If >>> data has been left in the buffer, it will be lost unless a flush >>> is done explicitly. >>> >>> While it is the case that this would seem to speed up >>> the close method, some might argue that the loss of data is >>> not good software engineering, thus impacting system reliability. >>> People will use: >>> sp.flush(); >>> sp.close(); >>> as a serial port idiom, if close does not automatically flush. >>> >>> If flush does not precede close, >>> the possible loss of data should be taken into >>> account at the programmers' level, or it is a semantic error. >>> >>> Others argue that a slow serial line will delay the delivery of >>> data for so long that the close will appear stalled. >>> >>> Corner-point: The emperor has no close. >>> >>> Suppose the serial device gets all stuffed up and data >>> cannot be delivered. In such a case, the close will never >>> finish with the flush and the serial port will never be released. >>> >>> In such a case, other programs (and users) who need the resource >>> will be unable to access it. >>> >>> Digression: once I went to a wedding on a boat where the head >>> was all stuffed up. Users were unable to flush and the >>> OutputStream never closed... :( >>> >>> A serial port is a system wide resource for which many applications >>> may contend. Once it is assigned to a process, in theory, no other >>> application may usurp it. >>> >>> Wont deadlock from unreleased resources impact system reliability? >>> >>> So, on the one hand we adversely impact system reliability with >>> increased chance of deadlock, or adversely impact system >>> reliability >>> with increased chance of data loss. >>> >>> To address the corner-point, the flush might need a time-out. >>> Perhaps >>> this can be computed as a function of the serial port data rate and >>> the >>> amount of data in the buffer. >>> >>> Please let me know if I am missing something. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Fri Sep 29 09:45:27 2006 From: gergg at cox.net (Gregg Wonderly) Date: Fri, 29 Sep 2006 10:45:27 -0500 Subject: [Rxtx] close != flush and may != close! In-Reply-To: <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> References: <451821E2.2020100@cox.net> <5E812523-AD5C-4827-8070-174FB714F321@buechse.de> <45199BC9.5010002@cox.net> <51F98070-0E9C-4C82-A4B9-4CED713BC166@buechse.de> <724D8240-72B4-4C30-83C2-A4D439595FB7@buechse.de> <451BD43F.3000204@cox.net> <1D24404E-A8CD-407F-A95C-564B76C0E133@buechse.de> <451C7358.8020701@cox.net> <48DBD137-3DB9-403A-9BC3-022E5D800B00@buechse.de> Message-ID: <451D3F97.5060802@cox.net> Joachim Buechse wrote: > Gregg, I also think that we are talking past each other, let me try > to restate what I want to say. > If you do not agree with the above, maybe you can provide a concrete > example where it will create problems or make things overly/more > complicated. I think that I was probably not interpreting the correct differentiation between Port.close() and Port.InputStream/OutputStream.close() in your posts. Since Port.close() has no access to the top layer of Streams, you are right that it can't guarentee flush(). Doug was discussing no flush in I/O Streams and that was alarming me. A close in any OutputStream implementation, must include the sematics of flush, before close(). If Port has a base OutputStream wrapper, calls to its close must include flush. Only Port.close() has the freedom to stop all I/O and summarily disconnect from the port. > BTW: Socket and HttpUrlConnection are much better examples then Swing > where java code actually works cross-platform. Socket and HttpUrlConnection have a much simpler task of being portable. I was using Swing as an example of the extreme of portability. There are so many least common denominator decisions to make with swing, to try and make sure that all needed functionality can be implemented some how. Thus, raw graphics card buffer access is not provided, nor is direct access to common graphics libraries. Instead, there is a wrapper above that level that allows abstractions to those kinds of things, but without direct access. So, if you want to do fancy drawing effects, you loose, and have to code them directly in terms of basic drawing operations, instead of being able to draw patterns for example. But gradient painting is an API thing so that if the graphics environment can make that easier/faster, it's done for you. It's these kinds of issues that I was trying to drive at. Gregg Wonderly From ajmas at sympatico.ca Fri Sep 29 14:09:00 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Fri, 29 Sep 2006 16:09:00 -0400 Subject: [Rxtx] Serial Port selection GUI? Message-ID: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I know this is a little off-topic, but I am interested in looking for a good GUI for dealing with serial port selection and configuration. Given that everyone on this list is dealing with serial ports, I am hoping that you have examples of what you think are good GUIs for doing this. If we come to a general consensus, then maybe providing a standard component that we can all use would be the end result (it could be me or someone else who implements it). Andre From lyon at docjava.com Fri Sep 29 07:30:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Fri, 29 Sep 2006 09:30:50 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, You may call System.exit(0) when threads are running or blocked. The following example demonstrates this. The threads never finish running, because System.exit(0) terminates the JVM. Thanks! - DL public class ThreadTest { public static void main(String args[]) { int numberOfThreads = 5; Thread t[] = new Thread[numberOfThreads]; System.out.println("Beginning thread test:"); for (int i=0; i < t.length; i++) { t[i] = new Thread(new Hello(i)); t[i].start(); } System.exit(0); } } class Hello implements Runnable { int i = 0; int numberOfTimesRun = 0; private static int totalNumberOfTimesRun = 0; Hello(int id) { i = id; } public static synchronized void incrementNumberOfTimes(){ totalNumberOfTimesRun++; } public void run() { for (int j = 0; j < 10; j++) { incrementNumberOfTimes(); System.out.println( "Hello #" + i + " numberOfTimesRun=" + numberOfTimesRun++ + "totalNumberOfTimesRun="+totalNumberOfTimesRun); try { Thread.sleep( (int) (Math.random() * 1000)); } // try catch (InterruptedException e) { e.printStackTrace(); } } // for System.out.println("Hello #" + i + " is done!"); } } >Hello Doug, > >- A blocked thread does stop you calling System.exit(). >- System.exit() does not execute any garbage collection or java? >finalization, so file handles etc. may still be open. They are? >however cleaned up when the unix JVM process exits/uwinds. >- A thread blocked in a kernel call will stop the java process from? >unwinding/exiting. The process is transformed into a zombie and holds? >on to it's resources until it can unwind. > >1) You may spawn a thread to call close (time-out mechanism), however? >you should not if this is inside a finalize call. >2) If the unix fd close never executes, you have a stale filehandle.? >However I never suggested it should not be called! >3) "Exiting" the Java VM before unix fd close returns changes? >nothing. Returning from Port.close() in the case that it can not? >complete defers the unresolvable problem to the next person trying to? >use the unusable port. All other ports and the VM in general (GC,? >Finalization) should still work fine. > >4) You don't know when the kernel has finished cleaning up after a? >unix fd close on a blocking fd. This is the same for IP sockets and? >files in Java. As no usefull information can be extracted from this,? >I don't think it's an issue. > >There are two informations you may want to know: > >Q: When has all data been sent on a port? >A: When Port.OutputStream.flush() returns, which may be called from? >Port.OutputStream.close() > >Q: When can I reuse/open a Port? >A: When Port.isCurrentlyOwned() returns false? >(CommPortOwnershipListener signals it) > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: > >> Hi Joachim, >> >> As I understand it, >> if close blocks the invokers' thread of execution >> it does not prevent another thread from calling >> System.exit(0). >> So, if we, as programmers, deem it OK to build our >> own time-out for the close mechanism, I think this should be >> possible, right? >> >> On the other hand, if close never executes, the danger of >> a serial port deadlock condition would seem to grow, right? >> >> In the typical case, exiting before the close has completed >> only defers the problem that the serial port cannot close, right? >> >> Even worse, how will I know (inside of my own program) when >> the close has completed? Will I need a call-back mechanism? >> (Listener) in >> order to be notified of this? >> >> Thanks! >> - Doug >> >> >>> My arguing must have been horribly unclear: > >> >>> All I want is a distinction between Port.close() and >>> Port.OutputStream.close(). >>> - Port.close() MUST NOT block (which means it can not flush). >>> - Port.OutputStream.close() MAY flush. >>> >>> Regarding you question: I think that OutputStream.flush() should NOT >>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>> exception if Port.close() is called. Turning the MAY into a "MUST" >>> can complicate the API implementation (some OSs will not unwind a >>> native tcdrain call and hence a handover mechanism / background >>> thread has to be used). In RXTX this thread already exists so the >>> RXTX implementation would not get systematicly more complicated. >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>> >>>> Hi All, >>>> Let me see if I can summarize the discussion on flushing so far: >>>> >>>> 1. Manual Flush: A close is just a close vs. >>>> 2. Automatic Flush: A close is a flush and then a close. >>>> >>>> On the one hand we can define a close for a serial port >>>> so that it closes the serial port and has no other role. If >>>> data has been left in the buffer, it will be lost unless a flush >>>> is done explicitly. >>>> >>>> While it is the case that this would seem to speed up >>>> the close method, some might argue that the loss of data is >>>> not good software engineering, thus impacting system reliability. >>>> People will use: >>>> sp.flush(); >>>> sp.close(); >>>> as a serial port idiom, if close does not automatically flush. >>>> >>>> If flush does not precede close, >>>> the possible loss of data should be taken into >>>> account at the programmers' level, or it is a semantic error. >>>> >>>> Others argue that a slow serial line will delay the delivery of >>>> data for so long that the close will appear stalled. >>>> >>>> Corner-point: The emperor has no close. >>>> >>>> Suppose the serial device gets all stuffed up and data >>>> cannot be delivered. In such a case, the close will never >>>> finish with the flush and the serial port will never be released. >>>> >>>> In such a case, other programs (and users) who need the resource >>>> will be unable to access it. >>>> >>>> Digression: once I went to a wedding on a boat where the head >>>> was all stuffed up. Users were unable to flush and the >>>> OutputStream never closed... :( >>>> >>>> A serial port is a system wide resource for which many applications >>>> may contend. Once it is assigned to a process, in theory, no other >>>> application may usurp it. >>>> >>>> Wont deadlock from unreleased resources impact system reliability? >>>> >>>> So, on the one hand we adversely impact system reliability with >>>> increased chance of deadlock, or adversely impact system? >>>> reliability >>>> with increased chance of data loss. >>>> >>>> To address the corner-point, the flush might need a time-out.? >>>> Perhaps >>>> this can be computed as a function of the serial port data rate and >>>> the >>>> amount of data in the buffer. >>>> >>>> Please let me know if I am missing something. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 29 15:20:15 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 15:20:15 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Let me see if I can summarize the discussion on flushing so far: > > 1. Manual Flush: A close is just a close vs. > 2. Automatic Flush: A close is a flush and then a close. > > On the one hand we can define a close for a serial port > so that it closes the serial port and has no other role. If > data has been left in the buffer, it will be lost unless a flush > is done explicitly. > > While it is the case that this would seem to speed up > the close method, some might argue that the loss of data is > not good software engineering, thus impacting system reliability. > People will use: > sp.flush(); > sp.close(); > as a serial port idiom, if close does not automatically flush. > > If flush does not precede close, > the possible loss of data should be taken into > account at the programmers' level, or it is a semantic error. > > Others argue that a slow serial line will delay the delivery of > data for so long that the close will appear stalled. > > Corner-point: The emperor has no close. > > Suppose the serial device gets all stuffed up and data > cannot be delivered. In such a case, the close will never > finish with the flush and the serial port will never be released. > > In such a case, other programs (and users) who need the resource > will be unable to access it. > > Digression: once I went to a wedding on a boat where the head > was all stuffed up. Users were unable to flush and the > OutputStream never closed... :( > > A serial port is a system wide resource for which many applications > may contend. Once it is assigned to a process, in theory, no other > application may usurp it. > > Wont deadlock from unreleased resources impact system reliability? > > So, on the one hand we adversely impact system reliability with > increased chance of deadlock, or adversely impact system reliability > with increased chance of data loss. > > To address the corner-point, the flush might need a time-out. Perhaps > this can be computed as a function of the serial port data rate and the > amount of data in the buffer. > > Please let me know if I am missing something. > output buffer empty events are flushes on Solaris and some other Unix Systems for all practical purposes. Every write has a flush on those systems as that is the only means of knowing when to send the event. Any Java API should abstract these details away from the programmer and behave the same on all systems. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Sep 29 19:30:42 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 29 Sep 2006 19:30:42 -0600 (MDT) Subject: [Rxtx] Serial Port selection GUI? In-Reply-To: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060929200900.LOPV24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Fri, 29 Sep 2006, Andre-John Mas wrote: > Hi, > > I know this is a little off-topic, but I am interested in looking for a > good GUI for dealing with serial port selection and configuration. Given > that everyone on this list is dealing with serial ports, I am hoping > that you have examples of what you think are good GUIs for doing this. > If we come to a general consensus, then maybe providing a standard > component that we can all use would be the end result (it could be me or > someone else who implements it). > Hi Andre What I've used for stand alone testing has been the blackbox application that shipped with Sun's CommAPI. It is wanting as a 'good' GUI. If you are interested in starting something, we can give you cvs access, web pages, .. what we have. It isnt much but could help get something going. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Sat Sep 30 03:56:41 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 30 Sep 2006 11:56:41 +0200 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Hello Doug, I'm not sure if your example was to prove that I'm right or wrong or just as an example. Your example is only on the Java level, the threads are not blocked, they are sleeping. To block a thread you have to drive it into a kernel call that does not return - the java VM implementation has no way of unwinding it from there. Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > Hi All, > You may call System.exit(0) when threads are running or > blocked. The following example demonstrates this. The threads > never finish running, because System.exit(0) terminates the JVM. > Thanks! > - DL > > public class ThreadTest { > > public static void main(String args[]) { > int numberOfThreads = 5; > Thread t[] = new Thread[numberOfThreads]; > System.out.println("Beginning thread test:"); > for (int i=0; i < t.length; i++) { > t[i] = new Thread(new Hello(i)); > t[i].start(); > } > System.exit(0); > } > } > > > class Hello implements Runnable { > int i = 0; > int numberOfTimesRun = 0; > private static int totalNumberOfTimesRun = 0; > > Hello(int id) { > i = id; > } > public static synchronized void incrementNumberOfTimes(){ > totalNumberOfTimesRun++; > } > public void run() { > for (int j = 0; j < 10; j++) { > incrementNumberOfTimes(); > System.out.println( > "Hello #" + i + > " numberOfTimesRun=" + numberOfTimesRun++ + > "totalNumberOfTimesRun="+totalNumberOfTimesRun); > try { > Thread.sleep( > (int) (Math.random() * 1000)); > } // try > catch (InterruptedException e) { > e.printStackTrace(); > } > } // for > System.out.println("Hello #" + i + " is done!"); > } > } >> Hello Doug, >> >> - A blocked thread does stop you calling System.exit(). >> - System.exit() does not execute any garbage collection or java >> finalization, so file handles etc. may still be open. They are >> however cleaned up when the unix JVM process exits/uwinds. >> - A thread blocked in a kernel call will stop the java process from >> unwinding/exiting. The process is transformed into a zombie and holds >> on to it's resources until it can unwind. >> >> 1) You may spawn a thread to call close (time-out mechanism), however >> you should not if this is inside a finalize call. >> 2) If the unix fd close never executes, you have a stale filehandle. >> However I never suggested it should not be called! >> 3) "Exiting" the Java VM before unix fd close returns changes >> nothing. Returning from Port.close() in the case that it can not >> complete defers the unresolvable problem to the next person trying to >> use the unusable port. All other ports and the VM in general (GC, >> Finalization) should still work fine. >> >> 4) You don't know when the kernel has finished cleaning up after a >> unix fd close on a blocking fd. This is the same for IP sockets and >> files in Java. As no usefull information can be extracted from this, >> I don't think it's an issue. >> >> There are two informations you may want to know: >> >> Q: When has all data been sent on a port? >> A: When Port.OutputStream.flush() returns, which may be called from >> Port.OutputStream.close() >> >> Q: When can I reuse/open a Port? >> A: When Port.isCurrentlyOwned() returns false >> (CommPortOwnershipListener signals it) >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >> >>> Hi Joachim, >>> >>> As I understand it, >>> if close blocks the invokers' thread of execution >>> it does not prevent another thread from calling >>> System.exit(0). >>> So, if we, as programmers, deem it OK to build our >>> own time-out for the close mechanism, I think this should be >>> possible, right? >>> >>> On the other hand, if close never executes, the danger of >>> a serial port deadlock condition would seem to grow, right? >>> >>> In the typical case, exiting before the close has completed >>> only defers the problem that the serial port cannot close, right? >>> >>> Even worse, how will I know (inside of my own program) when >>> the close has completed? Will I need a call-back mechanism >>> (Listener) in >>> order to be notified of this? >>> >>> Thanks! >>> - Doug >>> >>> >>>> My arguing must have been horribly unclear: >>>> >>>> All I want is a distinction between Port.close() and >>>> Port.OutputStream.close(). >>>> - Port.close() MUST NOT block (which means it can not flush). >>>> - Port.OutputStream.close() MAY flush. >>>> >>>> Regarding you question: I think that OutputStream.flush() >>>> should NOT >>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>> can complicate the API implementation (some OSs will not unwind a >>>> native tcdrain call and hence a handover mechanism / background >>>> thread has to be used). In RXTX this thread already exists so the >>>> RXTX implementation would not get systematicly more complicated. >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>> >>>>> Hi All, >>>>> Let me see if I can summarize the discussion on flushing so far: >>>>> >>>>> 1. Manual Flush: A close is just a close vs. >>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>> >>>>> On the one hand we can define a close for a serial port >>>>> so that it closes the serial port and has no other role. If >>>>> data has been left in the buffer, it will be lost unless a flush >>>>> is done explicitly. >>>>> >>>>> While it is the case that this would seem to speed up >>>>> the close method, some might argue that the loss of data is >>>>> not good software engineering, thus impacting system >>>>> reliability. >>>>> People will use: >>>>> sp.flush(); >>>>> sp.close(); >>>>> as a serial port idiom, if close does not automatically flush. >>>>> >>>>> If flush does not precede close, >>>>> the possible loss of data should be taken into >>>>> account at the programmers' level, or it is a semantic error. >>>>> >>>>> Others argue that a slow serial line will delay the delivery of >>>>> data for so long that the close will appear stalled. >>>>> >>>>> Corner-point: The emperor has no close. >>>>> >>>>> Suppose the serial device gets all stuffed up and data >>>>> cannot be delivered. In such a case, the close will never >>>>> finish with the flush and the serial port will never be >>>>> released. >>>>> >>>>> In such a case, other programs (and users) who need the resource >>>>> will be unable to access it. >>>>> >>>>> Digression: once I went to a wedding on a boat where the head >>>>> was all stuffed up. Users were unable to flush and the >>>>> OutputStream never closed... :( >>>>> >>>>> A serial port is a system wide resource for which many >>>>> applications >>>>> may contend. Once it is assigned to a process, in theory, no >>>>> other >>>>> application may usurp it. >>>>> >>>>> Wont deadlock from unreleased resources impact system >>>>> reliability? >>>>> >>>>> So, on the one hand we adversely impact system reliability with >>>>> increased chance of deadlock, or adversely impact system >>>>> reliability >>>>> with increased chance of data loss. >>>>> >>>>> To address the corner-point, the flush might need a time-out. >>>>> Perhaps >>>>> this can be computed as a function of the serial port data >>>>> rate and >>>>> the >>>>> amount of data in the buffer. >>>>> >>>>> Please let me know if I am missing something. >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 04:09:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 06:09:08 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: Message-ID: Hi All, Please note the following javadoc on the close method in the CommPortInterface. Should it be modified to mention the flush? The goal is to provide a abstract specification that we can implement on multiple platforms, as Trent suggests. Thanks! - Doug P.S. IMHO, an automatic flush could be an option, like on the PrintStream. autoFlush - A boolean; if true, the output buffer will be flushed whenever a byte array is written, the close method is invoked, or a newline character or byte ('\n') is written. In the world of real-time control, autoFlush may be important. Here is what I have so far: public interface CommPortInterface { /** * @return the name of this port. */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); } >On Fri, 29 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> Let me see if I can summarize the discussion on flushing so far: >> >> 1. Manual Flush: A close is just a close vs. >> 2. Automatic Flush: A close is a flush and then a close. >> >> On the one hand we can define a close for a serial port >> so that it closes the serial port and has no other role. If >> data has been left in the buffer, it will be lost unless a flush >> is done explicitly. >> >> While it is the case that this would seem to speed up >> the close method, some might argue that the loss of data is >> not good software engineering, thus impacting system reliability. >> People will use: >> sp.flush(); >> sp.close(); >> as a serial port idiom, if close does not automatically flush. >> >> If flush does not precede close, >> the possible loss of data should be taken into >> account at the programmers' level, or it is a semantic error. >> >> Others argue that a slow serial line will delay the delivery of >> data for so long that the close will appear stalled. >> >> Corner-point: The emperor has no close. >> >> Suppose the serial device gets all stuffed up and data >> cannot be delivered. In such a case, the close will never >> finish with the flush and the serial port will never be released. >> >> In such a case, other programs (and users) who need the resource >> will be unable to access it. >> >> Digression: once I went to a wedding on a boat where the head >> was all stuffed up. Users were unable to flush and the >> OutputStream never closed... :( >> >> A serial port is a system wide resource for which many applications >> may contend. Once it is assigned to a process, in theory, no other >> application may usurp it. >> >> Wont deadlock from unreleased resources impact system reliability? >> >> So, on the one hand we adversely impact system reliability with >> increased chance of deadlock, or adversely impact system reliability >> with increased chance of data loss. >> >> To address the corner-point, the flush might need a time-out. Perhaps >> this can be computed as a function of the serial port data rate and the >> amount of data in the buffer. >> >> Please let me know if I am missing something. >> > >output buffer empty events are flushes on Solaris and some other Unix >Systems for all practical purposes. Every write has a flush on those >systems as that is the only means of knowing when to send the event. > >Any Java API should abstract these details away from the programmer and >behave the same on all systems. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sat Sep 30 05:43:04 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 07:43:04 -0400 Subject: [Rxtx] gui v1.0 Message-ID: Hi All, Here is my first attempt at GUI for serial ports: http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp The features: 1. It works on PPC Mac, x86Linux and WinDOZE. 2. It persists the settings from one run to the next in user preferences. 3. It only configures one serial port (if you need to communicate with many serial ports at the same time, this is not for you). 4. It uses Swing 5. It can probably work on other platforms, I just don't have the native methods for the jar files linked into the web start application, yet. 6. It is simple looking. Please let me know what you think of it. Thanks! - DL From lyon at docjava.com Sat Sep 30 06:41:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 08:41:26 -0400 Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Hi Joachim, Can you provide an example of the kind of blocked thread you are speaking about? Thanks! - DL >Hello Doug, > >I'm not sure if your example was to prove that I'm right or wrong or? >just as an example. Your example is only on the Java level, the? >threads are not blocked, they are sleeping. To block a thread you? >have to drive it into a kernel call that does not return - the java? >VM implementation has no way of unwinding it from there. > >Best regards, >Joachim > >--- >Joachim B?chse >Softwarel?sungen und Beratung >Hadlaubsteig 2 >CH-8006 Z?rich > > >On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: > >> Hi All, >> You may call System.exit(0) when threads are running or >> blocked. The following example demonstrates this. The threads >> never finish running, because System.exit(0) terminates the JVM. >> Thanks! >> - DL >> >> public class ThreadTest { >> >> public static void main(String args[]) { >> int numberOfThreads = 5; >> Thread t[] = new Thread[numberOfThreads]; >> System.out.println("Beginning thread test:"); >> for (int i=0; i < t.length; i++) { >> t[i] = new Thread(new Hello(i)); >> t[i].start(); >> } >> System.exit(0); >> } >> } >> >> >> class Hello implements Runnable { >> int i = 0; >> int numberOfTimesRun = 0; >> private static int totalNumberOfTimesRun = 0; >> >> Hello(int id) { >> i = id; >> } >> public static synchronized void incrementNumberOfTimes(){ >> totalNumberOfTimesRun++; >> } >> public void run() { >> for (int j = 0; j < 10; j++) { >> incrementNumberOfTimes(); >> System.out.println( >> "Hello #" + i + >> " numberOfTimesRun=" + numberOfTimesRun++ + >> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >> try { >> Thread.sleep( >> (int) (Math.random() * 1000)); >> } // try >> catch (InterruptedException e) { >> e.printStackTrace(); >> } >> } // for >> System.out.println("Hello #" + i + " is done!"); >> } >> } >>> Hello Doug, >>> >>> - A blocked thread does stop you calling System.exit(). >>> - System.exit() does not execute any garbage collection or java >>> finalization, so file handles etc. may still be open. They are >>> however cleaned up when the unix JVM process exits/uwinds. >>> - A thread blocked in a kernel call will stop the java process from >>> unwinding/exiting. The process is transformed into a zombie and holds >>> on to it's resources until it can unwind. >>> >>> 1) You may spawn a thread to call close (time-out mechanism), however >>> you should not if this is inside a finalize call. >>> 2) If the unix fd close never executes, you have a stale filehandle. >>> However I never suggested it should not be called! >>> 3) "Exiting" the Java VM before unix fd close returns changes >>> nothing. Returning from Port.close() in the case that it can not >>> complete defers the unresolvable problem to the next person trying to >>> use the unusable port. All other ports and the VM in general (GC, >>> Finalization) should still work fine. >>> >>> 4) You don't know when the kernel has finished cleaning up after a >>> unix fd close on a blocking fd. This is the same for IP sockets and >>> files in Java. As no usefull information can be extracted from this, > >> I don't think it's an issue. >>> >>> There are two informations you may want to know: >>> >>> Q: When has all data been sent on a port? >>> A: When Port.OutputStream.flush() returns, which may be called from >>> Port.OutputStream.close() >>> >>> Q: When can I reuse/open a Port? >>> A: When Port.isCurrentlyOwned() returns false >>> (CommPortOwnershipListener signals it) >>> >>> Best regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich > >> >>> >>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>> >>>> Hi Joachim, >>>> >>>> As I understand it, >>>> if close blocks the invokers' thread of execution >>>> it does not prevent another thread from calling >>>> System.exit(0). >>>> So, if we, as programmers, deem it OK to build our >>>> own time-out for the close mechanism, I think this should be >>>> possible, right? >>>> >>>> On the other hand, if close never executes, the danger of >>>> a serial port deadlock condition would seem to grow, right? >>>> >>>> In the typical case, exiting before the close has completed >>>> only defers the problem that the serial port cannot close, right? >>>> >>>> Even worse, how will I know (inside of my own program) when >>>> the close has completed? Will I need a call-back mechanism >>>> (Listener) in >>>> order to be notified of this? >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>>> My arguing must have been horribly unclear: >>>>> >>>>> All I want is a distinction between Port.close() and >>>>> Port.OutputStream.close(). >>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>> - Port.OutputStream.close() MAY flush. >>>>> >>>>> Regarding you question: I think that OutputStream.flush()? >>>>> should NOT >>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>> can complicate the API implementation (some OSs will not unwind a >>>>> native tcdrain call and hence a handover mechanism / background >>>>> thread has to be used). In RXTX this thread already exists so the >>>>> RXTX implementation would not get systematicly more complicated. >>>>> >>>>> Best regards, >>>>> Joachim >>>>> >>>>> --- >>>>> Joachim B?chse >>>>> Softwarel?sungen und Beratung >>>>> Hadlaubsteig 2 >>>>> CH-8006 Z?rich >>>>> >>>>> >>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>> >>>>>> Hi All, >>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>> >>>>>> 1. Manual Flush: A close is just a close vs. >>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>> >>>>>> On the one hand we can define a close for a serial port >>>>>> so that it closes the serial port and has no other role. If >>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>> is done explicitly. >>>>>> >>>>>> While it is the case that this would seem to speed up >>>>>> the close method, some might argue that the loss of data is >>>>>> not good software engineering, thus impacting system? >>>>>> reliability. >>>>>> People will use: >>>>>> sp.flush(); >>>>>> sp.close(); >>>>>> as a serial port idiom, if close does not automatically flush. >>>>>> >>>>>> If flush does not precede close, >>>>>> the possible loss of data should be taken into >>>>>> account at the programmers' level, or it is a semantic error. >>>>>> >>>>>> Others argue that a slow serial line will delay the delivery of >>>>>> data for so long that the close will appear stalled. >>>>>> >>>>>> Corner-point: The emperor has no close. >>>>>> >>>>>> Suppose the serial device gets all stuffed up and data >>>>>> cannot be delivered. In such a case, the close will never >>>>>> finish with the flush and the serial port will never be? >>>>>> released. >>>>>> >>>>>> In such a case, other programs (and users) who need the resource >>>>>> will be unable to access it. >>>>>> >>>>>> Digression: once I went to a wedding on a boat where the head >>>>>> was all stuffed up. Users were unable to flush and the >>>>>> OutputStream never closed... :( >>>>>> >>>>>> A serial port is a system wide resource for which many > >>>>> applications >>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>> other >>>>>> application may usurp it. >>>>>> >>>>>> Wont deadlock from unreleased resources impact system? >>>>>> reliability? >>>>>> >>>>>> So, on the one hand we adversely impact system reliability with >>>>>> increased chance of deadlock, or adversely impact system >>>>>> reliability >>>>>> with increased chance of data loss. >>>>>> >>>>>> To address the corner-point, the flush might need a time-out. > >>>>> Perhaps >>>>>> this can be computed as a function of the serial port data? >>>>>> rate and >>>>>> the >>>>>> amount of data in the buffer. >>>>>> >>>>>> Please let me know if I am missing something. >>>>>> >>>>>> Thanks! >>>>>> - Doug >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Sat Sep 30 09:06:42 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Sat, 30 Sep 2006 11:06:42 -0400 Subject: [Rxtx] gui v1.0 Message-ID: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looks fine. If this is made available as a panel, then it could easily be used in situations where multiple serial ports need to be configured, or where someone wants to embed it into another panel. While I haven't seen your soure code, allowing to 'hide' or 'gray-out' certain fields could be handy. Some use cases seem to indicate that sometimes the extra settings are hidden by some applications since they are assumed values. BTW In case you are interested I did a quick search with Google to see some dialogs already implemented: http://ajmas.dyndns.org/serialports/ The vast majority use a simple layout you suggested. The main exception seems to be the MacOS 9 selector where images are used for the ports. I was also wondering whether a URL format could be handy for serial port specification. For example: serial://com1?4800,1,8,none,none serial://dev/myport?4800,1,8,none,none But this last point is really the subject of another e-mail. Andre > > From: "Dr. Douglas Lyon" > Date: 2006/09/30 Sat AM 07:43:04 EDT > To: RXTX Developers and Users > Subject: [Rxtx] gui v1.0 > > Hi All, > Here is my first attempt at GUI for serial ports: > http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > > The features: > 1. It works on PPC Mac, x86Linux and WinDOZE. > 2. It persists the settings from one run to the next in user preferences. > 3. It only configures one serial port (if you need to communicate with many > serial ports at the same time, this is not for you). > 4. It uses Swing > 5. It can probably work on other platforms, I just don't have > the native methods for the jar files linked into the web start application, > yet. > 6. It is simple looking. > > Please let me know what you think of it. > > Thanks! > - DL > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sat Sep 30 10:22:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 30 Sep 2006 12:22:55 -0400 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Hi All, Here is an example of how you might use my serial port panel: public static void main(String[] args) { final ClosableJFrame cf = new ClosableJFrame(); Container c = cf.getContentPane(); c.add( new RunSerialPortPanel() { public void run() { SerialPortBean x1 = getValue(); System.out.println(x1); cf.pack(); } }); cf.pack(); cf.setVisible(true); } The run method is invoke when the user click "OK" in the panel. The SerialPortBean is then serialized into the user preferences and the instance of the SerialPortBean value is returned from a getValue invocation. The FlowControl is set to be the same for both input and output. That might be limiting, for some people, I don't know. The implementation of the RunSerialPortPanel is working, but it is not really clean, yet. If people like this sort of thing, I can clean it up and release the source code as a part of the JCP reference implementation (i.e., a sample to show how this might be done). Do people care about an AWT version? Thanks! - DL >Looks fine. If this is made available as a panel, then it could >easily be used in situations where multiple serial ports need to be >configured, or where someone wants to embed it into another panel. > >While I haven't seen your soure code, allowing to 'hide' or >'gray-out' certain fields could be handy. Some use cases seem to >indicate that sometimes the extra settings are hidden by some >applications since they are assumed values. > >BTW In case you are interested I did a quick search with Google >to see some dialogs already implemented: > >http://ajmas.dyndns.org/serialports/ > >The vast majority use a simple layout you suggested. The main >exception seems to be the MacOS 9 selector where images are used for >the ports. > >I was also wondering whether a URL format could be handy for >serial port specification. For example: > > serial://com1?4800,1,8,none,none > > serial://dev/myport?4800,1,8,none,none > >But this last point is really the subject of another e-mail. > >Andre > >> >> From: "Dr. Douglas Lyon" >> Date: 2006/09/30 Sat AM 07:43:04 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] gui v1.0 >> >> Hi All, >> Here is my first attempt at GUI for serial ports: >> >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp >> >> The features: >> 1. It works on PPC Mac, x86Linux and WinDOZE. >> 2. It persists the settings from one run to the next in user preferences. >> 3. It only configures one serial port (if you need to communicate with many >> serial ports at the same time, this is not for you). >> 4. It uses Swing >> 5. It can probably work on other platforms, I just don't have >> the native methods for the jar files linked into the web start application, >> yet. >> 6. It is simple looking. >> >> Please let me know what you think of it. >> >> Thanks! >> - DL >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Sep 30 11:05:47 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 30 Sep 2006 14:05:47 -0300 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <360bc8300609301005r4b389a44mc3be845b7cbdb759@mail.gmail.com> Great work Doug!!! Maybe an AWT could be of any use. But a Swing one is more than enough. Cheers, Manuel 2006/9/30, Dr. Douglas Lyon : > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? > Thanks! > - DL > > >Looks fine. If this is made available as a panel, then it could > >easily be used in situations where multiple serial ports need to be > >configured, or where someone wants to embed it into another panel. > > > >While I haven't seen your soure code, allowing to 'hide' or > >'gray-out' certain fields could be handy. Some use cases seem to > >indicate that sometimes the extra settings are hidden by some > >applications since they are assumed values. > > > >BTW In case you are interested I did a quick search with Google > >to see some dialogs already implemented: > > > >http://ajmas.dyndns.org/serialports/ > > > >The vast majority use a simple layout you suggested. The main > >exception seems to be the MacOS 9 selector where images are used for > >the ports. > > > >I was also wondering whether a URL format could be handy for > >serial port specification. For example: > > > > serial://com1?4800,1,8,none,none > > > > serial://dev/myport?4800,1,8,none,none > > > >But this last point is really the subject of another e-mail. > > > >Andre > > > >> > >> From: "Dr. Douglas Lyon" > >> Date: 2006/09/30 Sat AM 07:43:04 EDT > >> To: RXTX Developers and Users > >> Subject: [Rxtx] gui v1.0 > >> > >> Hi All, > >> Here is my first attempt at GUI for serial ports: > >> > >>http://show.docjava.com:8086/book/cgij/code/jnlp/gui.run.RunSerialPortPanel.jnlp > >> > >> The features: > >> 1. It works on PPC Mac, x86Linux and WinDOZE. > >> 2. It persists the settings from one run to the next in user preferences. > >> 3. It only configures one serial port (if you need to communicate with many > >> serial ports at the same time, this is not for you). > >> 4. It uses Swing > >> 5. It can probably work on other platforms, I just don't have > >> the native methods for the jar files linked into the web start application, > >> yet. > >> 6. It is simple looking. > >> > >> Please let me know what you think of it. > >> > >> Thanks! > >> - DL > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Naranjo, Manuel Francisco naranjo.manuel at gmail.com From tjarvi at qbang.org Sat Sep 30 13:51:20 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:51:20 -0600 (MDT) Subject: [Rxtx] to flush or not to flush, that is a question In-Reply-To: References: <64C3C1A3-C44F-4520-B4FD-97DB5B2DE634@buechse.de> Message-ID: Reading with no timeout and no threshold should block while there is no data assuming the port is not open with O_NONBLOCK at the C level. (we currently have a bug in w32 but the others should do this). So from the JVM's perspective, this is a bit ugly as the thread is stuck in C libraries waiting for the (Native OS) kernel. On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi Joachim, > Can you provide an example of the kind of blocked thread > you are speaking about? > Thanks! > - DL > >> Hello Doug, >> >> I'm not sure if your example was to prove that I'm right or wrong or? >> just as an example. Your example is only on the Java level, the? >> threads are not blocked, they are sleeping. To block a thread you? >> have to drive it into a kernel call that does not return - the java? >> VM implementation has no way of unwinding it from there. >> >> Best regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 29.09.2006, at 15:30, Dr. Douglas Lyon wrote: >> >>> Hi All, >>> You may call System.exit(0) when threads are running or >>> blocked. The following example demonstrates this. The threads >>> never finish running, because System.exit(0) terminates the JVM. >>> Thanks! >>> - DL >>> >>> public class ThreadTest { >>> >>> public static void main(String args[]) { >>> int numberOfThreads = 5; >>> Thread t[] = new Thread[numberOfThreads]; >>> System.out.println("Beginning thread test:"); >>> for (int i=0; i < t.length; i++) { >>> t[i] = new Thread(new Hello(i)); >>> t[i].start(); >>> } >>> System.exit(0); >>> } >>> } >>> >>> >>> class Hello implements Runnable { >>> int i = 0; >>> int numberOfTimesRun = 0; >>> private static int totalNumberOfTimesRun = 0; >>> >>> Hello(int id) { >>> i = id; >>> } >>> public static synchronized void incrementNumberOfTimes(){ >>> totalNumberOfTimesRun++; >>> } >>> public void run() { >>> for (int j = 0; j < 10; j++) { >>> incrementNumberOfTimes(); >>> System.out.println( >>> "Hello #" + i + >>> " numberOfTimesRun=" + numberOfTimesRun++ + >>> "totalNumberOfTimesRun="+totalNumberOfTimesRun); >>> try { >>> Thread.sleep( >>> (int) (Math.random() * 1000)); >>> } // try >>> catch (InterruptedException e) { >>> e.printStackTrace(); >>> } >>> } // for >>> System.out.println("Hello #" + i + " is done!"); >>> } >>> } >>>> Hello Doug, >>>> >>>> - A blocked thread does stop you calling System.exit(). >>>> - System.exit() does not execute any garbage collection or java >>>> finalization, so file handles etc. may still be open. They are >>>> however cleaned up when the unix JVM process exits/uwinds. >>>> - A thread blocked in a kernel call will stop the java process from >>>> unwinding/exiting. The process is transformed into a zombie and holds >>>> on to it's resources until it can unwind. >>>> >>>> 1) You may spawn a thread to call close (time-out mechanism), however >>>> you should not if this is inside a finalize call. >>>> 2) If the unix fd close never executes, you have a stale filehandle. >>>> However I never suggested it should not be called! >>>> 3) "Exiting" the Java VM before unix fd close returns changes >>>> nothing. Returning from Port.close() in the case that it can not >>>> complete defers the unresolvable problem to the next person trying to >>>> use the unusable port. All other ports and the VM in general (GC, >>>> Finalization) should still work fine. >>>> >>>> 4) You don't know when the kernel has finished cleaning up after a >>>> unix fd close on a blocking fd. This is the same for IP sockets and >>>> files in Java. As no usefull information can be extracted from this, >> >> I don't think it's an issue. >>>> >>>> There are two informations you may want to know: >>>> >>>> Q: When has all data been sent on a port? >>>> A: When Port.OutputStream.flush() returns, which may be called from >>>> Port.OutputStream.close() >>>> >>>> Q: When can I reuse/open a Port? >>>> A: When Port.isCurrentlyOwned() returns false >>>> (CommPortOwnershipListener signals it) >>>> >>>> Best regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >> >> >>>> >>>> On 29.09.2006, at 13:17, Dr. Douglas Lyon wrote: >>>> >>>>> Hi Joachim, >>>>> >>>>> As I understand it, >>>>> if close blocks the invokers' thread of execution >>>>> it does not prevent another thread from calling >>>>> System.exit(0). >>>>> So, if we, as programmers, deem it OK to build our >>>>> own time-out for the close mechanism, I think this should be >>>>> possible, right? >>>>> >>>>> On the other hand, if close never executes, the danger of >>>>> a serial port deadlock condition would seem to grow, right? >>>>> >>>>> In the typical case, exiting before the close has completed >>>>> only defers the problem that the serial port cannot close, right? >>>>> >>>>> Even worse, how will I know (inside of my own program) when >>>>> the close has completed? Will I need a call-back mechanism >>>>> (Listener) in >>>>> order to be notified of this? >>>>> >>>>> Thanks! >>>>> - Doug >>>>> >>>>> >>>>>> My arguing must have been horribly unclear: >>>>>> >>>>>> All I want is a distinction between Port.close() and >>>>>> Port.OutputStream.close(). >>>>>> - Port.close() MUST NOT block (which means it can not flush). >>>>>> - Port.OutputStream.close() MAY flush. >>>>>> >>>>>> Regarding you question: I think that OutputStream.flush()? >>>>>> should NOT >>>>>> timeout (and I'm 99% sure Gregg agrees;-). It MAY return with an >>>>>> exception if Port.close() is called. Turning the MAY into a "MUST" >>>>>> can complicate the API implementation (some OSs will not unwind a >>>>>> native tcdrain call and hence a handover mechanism / background >>>>>> thread has to be used). In RXTX this thread already exists so the >>>>>> RXTX implementation would not get systematicly more complicated. >>>>>> >>>>>> Best regards, >>>>>> Joachim >>>>>> >>>>>> --- >>>>>> Joachim B?chse >>>>>> Softwarel?sungen und Beratung >>>>>> Hadlaubsteig 2 >>>>>> CH-8006 Z?rich >>>>>> >>>>>> >>>>>> On 29.09.2006, at 09:45, Dr. Douglas Lyon wrote: >>>>>> >>>>>>> Hi All, >>>>>>> Let me see if I can summarize the discussion on flushing so far: >>>>>>> >>>>>>> 1. Manual Flush: A close is just a close vs. >>>>>>> 2. Automatic Flush: A close is a flush and then a close. >>>>>>> >>>>>>> On the one hand we can define a close for a serial port >>>>>>> so that it closes the serial port and has no other role. If >>>>>>> data has been left in the buffer, it will be lost unless a flush >>>>>>> is done explicitly. >>>>>>> >>>>>>> While it is the case that this would seem to speed up >>>>>>> the close method, some might argue that the loss of data is >>>>>>> not good software engineering, thus impacting system? >>>>>>> reliability. >>>>>>> People will use: >>>>>>> sp.flush(); >>>>>>> sp.close(); >>>>>>> as a serial port idiom, if close does not automatically flush. >>>>>>> >>>>>>> If flush does not precede close, >>>>>>> the possible loss of data should be taken into >>>>>>> account at the programmers' level, or it is a semantic error. >>>>>>> >>>>>>> Others argue that a slow serial line will delay the delivery of >>>>>>> data for so long that the close will appear stalled. >>>>>>> >>>>>>> Corner-point: The emperor has no close. >>>>>>> >>>>>>> Suppose the serial device gets all stuffed up and data >>>>>>> cannot be delivered. In such a case, the close will never >>>>>>> finish with the flush and the serial port will never be? >>>>>>> released. >>>>>>> >>>>>>> In such a case, other programs (and users) who need the resource >>>>>>> will be unable to access it. >>>>>>> >>>>>>> Digression: once I went to a wedding on a boat where the head >>>>>>> was all stuffed up. Users were unable to flush and the >>>>>>> OutputStream never closed... :( >>>>>>> >>>>>>> A serial port is a system wide resource for which many >> >>>>> applications >>>>>>> may contend. Once it is assigned to a process, in theory, no? >>>>>>> other >>>>>>> application may usurp it. >>>>>>> >>>>>>> Wont deadlock from unreleased resources impact system? >>>>>>> reliability? >>>>>>> >>>>>>> So, on the one hand we adversely impact system reliability with >>>>>>> increased chance of deadlock, or adversely impact system >>>>>>> reliability >>>>>>> with increased chance of data loss. >>>>>>> >>>>>>> To address the corner-point, the flush might need a time-out. >> >>>>> Perhaps >>>>>>> this can be computed as a function of the serial port data? >>>>>>> rate and >>>>>>> the >>>>>>> amount of data in the buffer. >>>>>>> >>>>>>> Please let me know if I am missing something. >>>>>>> >>>>>>> Thanks! >>>>>>> - Doug >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Rxtx mailing list >>>>>>> Rxtx at qbang.org >>>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sat Sep 30 13:54:01 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 30 Sep 2006 13:54:01 -0600 (MDT) Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: On Sat, 30 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > Here is an example of how you might use > my serial port panel: > public static void main(String[] args) { > final ClosableJFrame cf = new ClosableJFrame(); > Container c = cf.getContentPane(); > c.add( > new RunSerialPortPanel() { > public void run() { > SerialPortBean x1 = getValue(); > System.out.println(x1); > cf.pack(); > } > }); > cf.pack(); > cf.setVisible(true); > } > > The run method is invoke when the user click "OK" in the panel. > The SerialPortBean is then serialized into the user preferences and the > instance of the SerialPortBean value is returned from a getValue invocation. > > The FlowControl is set to be the same for both input and output. That might > be limiting, for some people, I don't know. > > The implementation of the RunSerialPortPanel is working, but it is not > really clean, yet. If people like this sort of thing, I can clean it up and > release the source code as a part of the JCP reference implementation (i.e., > a sample to show how this might be done). > > Do people care about an AWT version? One advantage of AWT is less complete Java implementations can use the code. GCJ with GNU Classpath is one of these. Perhaps some Java ME's (cell phones). I don't think its that big of a deal though. -- Trent Jarvi tjarvi at qbang.org From Bob_Jacobsen at lbl.gov Sat Sep 30 12:46:27 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 30 Sep 2006 11:46:27 -0700 Subject: [Rxtx] gui v1.0, example of use In-Reply-To: References: <20060930150642.YLMW1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Very nice!! One thing that would be useful is a way for the invoking code to limit the GUI. If the program is for talking to a particular piece of hardware which has certain requirements, e.g. you know the right answer, it would be better not to have the user have to set it correctly. *) If it's a question with only one correct answer, e.g. even parity is required, it would be good if the invoking program had an easy way to set that answer and make the corresponding control not show (set it not visible, or just not create it in the first place) *) If there are a restricted range, e.g. the device only talks at 1200 or 9600 baud, it would be good to not display other choices. Sorry to sound like I'm asking you to do even more work; I certainly appreciate what you've contributed so far. If you'd like, I'd be happy to try to figure out a way to do this consistent with the structure of your existing code. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 07:26:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 09:26:32 -0400 Subject: [Rxtx] loopback puzzle Message-ID: I am trying to understand basic things about serial ports on the Mac. The SerialDemo.java program from Sun's javax.CommPort program displays 2 panels: characters going out to a port, and characters coming in from it. Question: if I have nothing attached to the port, why does anything get echoed from the outgoing panel to the incoming one? My mental model says nothing should happen until there is some hardware attached to the port. Nothing I have looked for in the code tells me there is any software connection between the outgoing and incoming streams. Please tell me what is broken in my brain. sj From joachim at buechse.de Wed Sep 6 07:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 15:59:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: References: Message-ID: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> You are not by any chance using the cu.modem port? On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > I am trying to understand basic things about serial ports on the Mac. > The SerialDemo.java program from Sun's javax.CommPort program > displays 2 panels: characters going out to a port, and characters > coming in from it. Question: if I have nothing attached to the port, > why does anything get echoed from the outgoing panel to the incoming > one? My mental model says nothing should happen until there is > some hardware attached to the port. > > Nothing I have looked for in the code tells me there is any software > connection between the outgoing and incoming streams. > Please tell me what is broken in my brain. > sj > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From sjudd at seas.upenn.edu Wed Sep 6 08:49:32 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 10:49:32 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> Message-ID: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> I used all the options available, and all had the same effect. I stuck in a loop that ran through the ports enumerated by CommPortIdentifier.getPortIdentifiers() and there are only 2 of them: /dev/cu.modem and /dev/tty.modem both of which are of "type 1" and have no "owner". The way you phrase your question leads me to believe there is something notoriously obvious about cu.modem, but Google is not making anything obvious for me. Please explain. sj On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > You are not by any chance using the cu.modem port? > > On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: > >> I am trying to understand basic things about serial ports on the Mac. >> The SerialDemo.java program from Sun's javax.CommPort program >> displays 2 panels: characters going out to a port, and characters >> coming in from it. Question: if I have nothing attached to the port, >> why does anything get echoed from the outgoing panel to the incoming >> one? My mental model says nothing should happen until there is >> some hardware attached to the port. >> >> Nothing I have looked for in the code tells me there is any software >> connection between the outgoing and incoming streams. >> Please tell me what is broken in my brain. >> sj From joachim at buechse.de Wed Sep 6 08:55:32 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 16:55:32 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> There is an internal modem connected to this port... that's the device responding to you requests. Try AT I0 ;-) On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > I used all the options available, and all had the same effect. > I stuck in a loop that ran through the ports enumerated by > CommPortIdentifier.getPortIdentifiers() > and there are only 2 of them: /dev/cu.modem and /dev/tty.modem > both of which are of "type 1" and have no "owner". > > The way you phrase your question leads me to believe there is > something notoriously obvious about cu.modem, but Google is not > making anything obvious for me. Please explain. > sj > > > On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: > >> You are not by any chance using the cu.modem port? >> >> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >> >>> I am trying to understand basic things about serial ports on the >>> Mac. >>> The SerialDemo.java program from Sun's javax.CommPort program >>> displays 2 panels: characters going out to a port, and characters >>> coming in from it. Question: if I have nothing attached to the port, >>> why does anything get echoed from the outgoing panel to the incoming >>> one? My mental model says nothing should happen until there is >>> some hardware attached to the port. >>> >>> Nothing I have looked for in the code tells me there is any software >>> connection between the outgoing and incoming streams. >>> Please tell me what is broken in my brain. >>> sj > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Wed Sep 6 09:37:49 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Wed, 6 Sep 2006 08:37:49 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> Message-ID: At 10:49 AM -0400 9/6/06, Dr. Stephen Judd wrote: >I used all the options available, and all had the same effect. >I stuck in a loop that ran through the ports enumerated by >CommPortIdentifier.getPortIdentifiers() >and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >both of which are of "type 1" and have no "owner". > >The way you phrase your question leads me to believe there is >something notoriously obvious about cu.modem, but Google is not >making anything obvious for me. Please explain. At first, the modem is probably in a "command mode", where it's echoing back the characters it sees. This dates back to the original Hayes modems, where you could type commands to tell it to dial, etc. Once the connection is made, it goes to "data mode", where it's just passing the characters through. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From sjudd at seas.upenn.edu Wed Sep 6 09:47:23 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Wed, 6 Sep 2006 11:47:23 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> Message-ID: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> hmmmmm. That was cryptic. "AT capital-I zero " means nothing to me, even after another half hour exploring. However, ";-)" does mean something. Perhaps I should check with you again. sj On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > There is an internal modem connected to this port... that's the > device responding to you requests. Try AT I0 ;-) > > On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: > >> I used all the options available, and all had the same effect. >> I stuck in a loop that ran through the ports enumerated by >> CommPortIdentifier.getPortIdentifiers() >> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >> both of which are of "type 1" and have no "owner". >> >> The way you phrase your question leads me to believe there is >> something notoriously obvious about cu.modem, but Google is not >> making anything obvious for me. Please explain. >> sj >> >> >> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >> >>> You are not by any chance using the cu.modem port? >>> >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>> >>>> I am trying to understand basic things about serial ports on the >>>> Mac. >>>> The SerialDemo.java program from Sun's javax.CommPort program >>>> displays 2 panels: characters going out to a port, and characters >>>> coming in from it. Question: if I have nothing attached to the >>>> port, >>>> why does anything get echoed from the outgoing panel to the >>>> incoming >>>> one? My mental model says nothing should happen until there is >>>> some hardware attached to the port. >>>> >>>> Nothing I have looked for in the code tells me there is any >>>> software >>>> connection between the outgoing and incoming streams. >>>> Please tell me what is broken in my brain. >>>> sj >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Wed Sep 6 11:15:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 6 Sep 2006 19:15:06 +0200 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <6D4D3BC0-D88E-4708-9677-F94250075797@buechse.de> ATI0 is a standard hayes command. Crtl-M (instead of simply return) is needed on the mac so that the modem accepts it as a command. The modem will respond with it's version info. This shows that you are not just talking to a cable but to an "inteligent lifeform" ;-) Best regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.09.2006, at 17:47, Dr. Stephen Judd wrote: > hmmmmm. That was cryptic. "AT capital-I zero " means nothing > to me, > even after another half hour exploring. > > However, ";-)" does mean something. Perhaps I should check with you > again. > sj > > On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> >>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From andy.dalton at gmail.com Thu Sep 7 11:12:57 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 13:12:57 -0400 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Greetings, I've seen in the archives some recent discussion between Trent and Pawan Kharbanda that looks like it's related to a problem I'm experiencing. I've downloaded and ran Pawan's test application and I am able to reproduce the problem with my hardware pretty quickly (with as little as 3 threads). Here's the end snipit of what happened: --------------------------------------------------------------------------------------------------------------------------- Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 Exception in thread "Thread ::: /dev/ttyUSB13" java.lang.NoClassDefFoundError: javax.comm/PortInUseException at javax.comm.RXTXPort.open(Native Method) at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread ::: /dev/ttyUSB50 Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 Exiting Thread ::: /dev/ttyUSB25 Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) # Problematic frame: # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid1449.log Exiting Thread ::: /dev/ttyUSB12 Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 Exiting Thread ::: /dev/ttyUSB29 Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 Exiting Thread ::: /dev/ttyUSB64 Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 Port /dev/ttyUSB1 is Opened 0x01 Sent # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Aborted --------------------------------------------------------------------------------------------------------------------------- I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB serial devices in Linux. Currently I can be communicating with up to 8 different devices at the same time. The problem is, I frequently get the same SIGSEGV seen above: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) # Problematic frame: # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a # # An error report file with more information is saved as hs_err_pid20656.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get that version to work at all with my existing software. Here's some information related to my setup: $ java -version java version "1.5.0_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) $ uname -a Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c #define DRIVER_VERSION "v1.4.3" If there's any additional information I might be able to provide, please let me know. Thanks in advance for your time as assistance. Andy From lyon at docjava.com Thu Sep 7 06:40:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 07 Sep 2006 08:40:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: Hi Steve, If you hook up a phone line to your built in phone jack on the mac, you will be able to dial the phone. This is why you are getting an echo. To see this, in action, with RXTX, use: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Goto Preferences:SerialPort Setup and select the /dev/cu.modem. If you add more serial ports (like keyspans 19-HS, etc..) you should see them listed in the pop-down choice menu. I use these devices to auto-dial the phone, with a long distance card. Now if I could only figure out how to monitize the application... Cheers! - Doug >hmmmmm. That was cryptic. "AT capital-I zero " means nothing? >to me, >even after another half hour exploring. > >However, ";-)" does mean something. Perhaps I should check with you? >again. >sj > >On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: > >> There is an internal modem connected to this port... that's the >> device responding to you requests. Try AT I0 ;-) >> >> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >> >>> I used all the options available, and all had the same effect. >>> I stuck in a loop that ran through the ports enumerated by >>> CommPortIdentifier.getPortIdentifiers() >>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>> both of which are of "type 1" and have no "owner". >>> >>> The way you phrase your question leads me to believe there is >>> something notoriously obvious about cu.modem, but Google is not >>> making anything obvious for me. Please explain. >>> sj >>> >>> >>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>> >>>> You are not by any chance using the cu.modem port? >>>> > >>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>> >>>>> I am trying to understand basic things about serial ports on the >>>>> Mac. >>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>> displays 2 panels: characters going out to a port, and characters >>>>> coming in from it. Question: if I have nothing attached to the? >>>>> port, >>>>> why does anything get echoed from the outgoing panel to the? >>>>> incoming >>>>> one? My mental model says nothing should happen until there is >>>>> some hardware attached to the port. >>>>> >>>>> Nothing I have looked for in the code tells me there is any? >>>>> software >>>>> connection between the outgoing and incoming streams. >>>>> Please tell me what is broken in my brain. >>>>> sj >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 7 18:38:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Sep 2006 18:38:35 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: On Thu, 7 Sep 2006, Andy Dalton wrote: > Greetings, > > I've seen in the archives some recent discussion between Trent and > Pawan Kharbanda that looks like it's related to a problem I'm > experiencing. I've downloaded and ran Pawan's test application and I > am able to reproduce the problem with my hardware pretty quickly (with > as little as 3 threads). Here's the end snipit of what happened: > > --------------------------------------------------------------------------------------------------------------------------- > > Cycle No (Thread ::: /dev/ttyUSB13) ::::::: 2 > Exception in thread "Thread ::: /dev/ttyUSB13" > java.lang.NoClassDefFoundError: javax.comm/PortInUseException > at javax.comm.RXTXPort.open(Native Method) > at javax.comm.RXTXPort.(RXTXPort.java:84)Exiting Thread > ::: /dev/ttyUSB50 > Cycle No (Thread ::: /dev/ttyUSB50) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB25 > Cycle No (Thread ::: /dev/ttyUSB25) ::::::: 2 > > at javax.comm.RXTXCommDriver.getCommPort(RXTXCommDriver.java:772) > at javax.comm.CommPortIdentifier.open(CommPortIdentifier.java:343) > at TestOpenClosePort$SerialThread.run(TestOpenClosePort.java:192) > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xaa30d73a, pid=1449, tid=2778098592 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode) > # Problematic frame: > # C [librxtxSerial.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid1449.log > Exiting Thread ::: /dev/ttyUSB12 > Cycle No (Thread ::: /dev/ttyUSB12) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB29 > Cycle No (Thread ::: /dev/ttyUSB29) ::::::: 2 > Exiting Thread ::: /dev/ttyUSB64 > Cycle No (Thread ::: /dev/ttyUSB64) ::::::: 2 > Port /dev/ttyUSB1 is Opened > 0x01 Sent > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Aborted > > --------------------------------------------------------------------------------------------------------------------------- > > I'm working with rxtx-2.1-7pre17 to communicate with 80 FTDI USB > serial devices in Linux. Currently I can be communicating with up to > 8 different devices at the same time. The problem is, I frequently > get the same SIGSEGV seen above: > > # > # An unexpected error has been detected by HotSpot Virtual Machine: > # > # SIGSEGV (0xb) at pc=0xa8b1673a, pid=20656, tid=2808978336 > # > # Java VM: Java HotSpot(TM) Client VM (1.5.0_05-b05 mixed mode) > # Problematic frame: > # C [librxtxSerial-2.1-7pre17.so+0x773a] initialise_event_info_struct+0x18a > # > # An error report file with more information is saved as hs_err_pid20656.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > > I've tried upgrading to rxtx-2.1-7r2; however, I can't seem to get > that version to work at all with my existing software. Here's some > information related to my setup: > > $ java -version > java version "1.5.0_08" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_08-b03) > Java HotSpot(TM) Client VM (build 1.5.0_08-b03, mixed mode) > > $ uname -a > Linux nestbed 2.6.17-gentoo-r7 #1 SMP Sat Sep 2 03:55:06 EDT 2006 i686 > Intel(R) Pentium(R) 4 CPU 3.00GHz GNU/Linux > > $ grep VERSION /usr/src/linux/drivers/usb/serial/ftdi_sio.c > #define DRIVER_VERSION "v1.4.3" > > If there's any additional information I might be able to provide, > please let me know. > > Thanks in advance for your time as assistance. > Hi Andy With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 is older and its easier to work with older binaries. But that is all you are gaining as far as I know. Compiling on your system should result in a usable library. I would be interested in knowing if you still have problems. In Pawan's case, the problem was resolved by upgrading the system, drivers and firmware on the multiport device. USB can be interesting this way too but less so on Linux. I was able to generate a crash but only after hours of hammering. So while there is probably a latent problem, I do not know of a case where it is reproducable like you mention with current rxtx. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Thu Sep 7 19:51:42 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Thu, 7 Sep 2006 21:51:42 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> Message-ID: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 > is older and its easier to work with older binaries. But that is all you > are gaining as far as I know. Compiling on your system should result in a > usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, drivers > and firmware on the multiport device. USB can be interesting this way too > but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case where it > is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Fri Sep 8 09:04:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Fri, 8 Sep 2006 09:04:05 -0600 Subject: [Rxtx] Port Locking / JVM Crashing Message-ID: <939A619A756047469C41EE9BA51890FB0455EACA@hqexchange3.dot.state.co.us> Andy, Trent is right I used the new Red Hat kernel 2.6 with rxtx 2.1-7 (final), I wasn't able to completely able to eliminate the problem but migrating to the latest kernel surely helped. I still see some locks but after many many cycles of opening and closing different comm ports. Thanks ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Andy Dalton Sent: Thursday, September 07, 2006 7:52 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Port Locking / JVM Crashing Hi Trent, Thank you for your response. When I tried the latest-and-greatest, I did compile it by hand as the libraries I'm using depend on the javax.comm.* package structure and not the gnu.io.* Does the 'contrib/ChangePackage.sh' script still work for rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper for the gnu.io packages? That's the only think I can think that might have caused me problems. Otherwise, I'll try it again and if I still run into problems, I'll let you know more specifically what problems I have. Thanks again for your help. Andy On 9/7/06, Trent Jarvi wrote: > > Hi Andy > > With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The > pre17 is older and its easier to work with older binaries. But that > is all you are gaining as far as I know. Compiling on your system > should result in a usable library. > > I would be interested in knowing if you still have problems. > > In Pawan's case, the problem was resolved by upgrading the system, > drivers and firmware on the multiport device. USB can be interesting > this way too but less so on Linux. > > I was able to generate a crash but only after hours of hammering. So > while there is probably a latent problem, I do not know of a case > where it is reproducable like you mention with current rxtx. > > -- > Trent Jarvi > tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Fri Sep 8 20:22:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 8 Sep 2006 20:22:13 -0600 (MDT) Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: Hi Andy The script mostly works though it's usually used to go the other way while preparing rxtx 2.0 for release. If you noticed the exception error you saw was a / instead of a . in the exception.. javax.comm/PortInUseException as I recall. ----------^ So its not perfect but that will not be the cause of the error you saw. On Thu, 7 Sep 2006, Andy Dalton wrote: > Hi Trent, > > Thank you for your response. When I tried the latest-and-greatest, I > did compile it by hand as the libraries I'm using depend on the > javax.comm.* package structure and not the gnu.io.* > > Does the 'contrib/ChangePackage.sh' script still work for > rxtx-2.1-7r2? If not, is there some javax.comm pass-through wrapper > for the gnu.io packages? That's the only think I can think that might > have caused me problems. > > Otherwise, I'll try it again and if I still run into problems, I'll > let you know more specifically what problems I have. > > Thanks again for your help. > > Andy > > On 9/7/06, Trent Jarvi wrote: >> >> Hi Andy >> >> With Gentoo, I would try recompiling rxtx-2.1-7 on your system. The pre17 >> is older and its easier to work with older binaries. But that is all you >> are gaining as far as I know. Compiling on your system should result in a >> usable library. >> >> I would be interested in knowing if you still have problems. >> >> In Pawan's case, the problem was resolved by upgrading the system, drivers >> and firmware on the multiport device. USB can be interesting this way too >> but less so on Linux. >> >> I was able to generate a crash but only after hours of hammering. So >> while there is probably a latent problem, I do not know of a case where it >> is reproducable like you mention with current rxtx. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From andy.dalton at gmail.com Fri Sep 8 22:21:40 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Sat, 9 Sep 2006 00:21:40 -0400 Subject: [Rxtx] Port Locking / JVM Crashing In-Reply-To: References: <9b1737410609071012i1af21519ma9466b466d7850f3@mail.gmail.com> <9b1737410609071851m1735f95fm6baf650db1286736@mail.gmail.com> Message-ID: <9b1737410609082121y1e3cbcfg9c14d1144c700888@mail.gmail.com> Trent, Okay, I took some time to look into why the latest-n-greatest wasn't working for me. There's a bug in src/RXTXCommDriver.java on line 362: System.setProperties(p); That blows away the pre-set system properties, so later calls to System.getProperty("os.name") in src/CommPortIdentifier.java returns null, which later causes a NullPointerException in the static initializer. Lines 363-366 update the existing System properties without throwing the existing properties away, so just commenting out that single line fixed things. I noticed that someone else ran into this problem back in early June: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20060529/126711.html Anyway, I'll try out this new version and see if it resolves my problem. Thanks once again for all your help. Andy On 9/8/06, Trent Jarvi wrote: > > Hi Andy > > The script mostly works though it's usually used to go the other way while > preparing rxtx 2.0 for release. If you noticed the exception error you > saw was a / instead of a . in the exception.. > > javax.comm/PortInUseException as I recall. > ----------^ > > So its not perfect but that will not be the cause of the error you saw. > From sjudd at seas.upenn.edu Mon Sep 11 14:35:36 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 16:35:36 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> Message-ID: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. Building on what I have learned from this group, my mental model has arrived at the point where I believe that the mere plugging in of a port expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) will automagically change the list of ports available to CommPortIdentifier.getPortIdentifiers(). Experiments say this is not true however. Using same SerialDemo as described below, the list does not change, even after plugging a live device into one of the resulting RS-232 ports, and restarting the app. What's broken now? my hardware? or still my head? sj On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > Hi Steve, > If you hook up a phone line to your > built in phone jack on the mac, you will be able to > dial the phone. This is why you are getting an echo. > To see this, in action, with RXTX, use: > http://show.docjava.com:8086/book/cgij/code/jnlp/ > addbk.JAddressBook.Main.jnlp > Goto Preferences:SerialPort Setup and select the /dev/cu.modem. > > If you add more serial ports (like keyspans 19-HS, etc..) you should > see them listed in the pop-down choice menu. > > I use these devices to auto-dial the phone, with a long > distance card. > > Now if I could only figure out how to monitize the application... > Cheers! > - Doug > > >> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >> to me, >> even after another half hour exploring. >> >> However, ";-)" does mean something. Perhaps I should check with you >> again. >> sj >> >> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >> >>> There is an internal modem connected to this port... that's the >>> device responding to you requests. Try AT I0 ;-) >>> >>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>> >>>> I used all the options available, and all had the same effect. >>>> I stuck in a loop that ran through the ports enumerated by >>>> CommPortIdentifier.getPortIdentifiers() >>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>> both of which are of "type 1" and have no "owner". >>>> >>>> The way you phrase your question leads me to believe there is >>>> something notoriously obvious about cu.modem, but Google is not >>>> making anything obvious for me. Please explain. >>>> sj >>>> >>>> >>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>> >>>>> You are not by any chance using the cu.modem port? >>>>> >>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>> >>>>>> I am trying to understand basic things about serial ports on the >>>>>> Mac. >>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>> displays 2 panels: characters going out to a port, and >>>>>> characters >>>>>> coming in from it. Question: if I have nothing attached to the >>>>>> port, >>>>>> why does anything get echoed from the outgoing panel to the >>>>>> incoming >>>>>> one? My mental model says nothing should happen until there is >>>>>> some hardware attached to the port. >>>>>> >>>>>> Nothing I have looked for in the code tells me there is any >>>>>> software >>>>>> connection between the outgoing and incoming streams. >>>>>> Please tell me what is broken in my brain. >>>>>> sj >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060911/e8adb1bb/attachment-0015.html From tjarvi at qbang.org Mon Sep 11 17:00:17 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:00:17 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The CommAPI 'specification' was written before ports could vanish and appear. There isn't a means of catching 'hotplug' events yet. For all practical purposes, the hardware should not change while using CommAPI 2.0. This shortfall has been discussed as a possible addition to future 'standards' which rxtx will support. For now, you have to adjust your mental image :) On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > > Building on what I have learned from this group, my mental model has > arrived at the point where I believe that the mere plugging in of a port > expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) > will automagically change the list of ports available to > CommPortIdentifier.getPortIdentifiers(). > > Experiments say this is not true however. Using same SerialDemo as > described below, the list does not change, even after plugging a live device > into one of the resulting RS-232 ports, and restarting the app. > > What's broken now? my hardware? or still my head? > sj > > On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> Hi Steve, >> If you hook up a phone line to your >> built in phone jack on the mac, you will be able to >> dial the phone. This is why you are getting an echo. >> To see this, in action, with RXTX, use: >> http://show.docjava.com:8086/book/cgij/code/jnlp/ >> addbk.JAddressBook.Main.jnlp >> Goto Preferences:SerialPort Setup and select the /dev/cu.modem. >> >> If you add more serial ports (like keyspans 19-HS, etc..) you should >> see them listed in the pop-down choice menu. >> >> I use these devices to auto-dial the phone, with a long >> distance card. >> >> Now if I could only figure out how to monitize the application... >> Cheers! >> - Doug >> >> >>> hmmmmm. That was cryptic. "AT capital-I zero " means nothing >>> to me, >>> even after another half hour exploring. >>> >>> However, ";-)" does mean something. Perhaps I should check with you >>> again. >>> sj >>> >>> On 2006 Sep 6, at 10:55 AM, Joachim Buechse wrote: >>> >>>> There is an internal modem connected to this port... that's the >>>> device responding to you requests. Try AT I0 ;-) >>>> >>>> On 06.09.2006, at 16:49, Dr. Stephen Judd wrote: >>>> >>>>> I used all the options available, and all had the same effect. >>>>> I stuck in a loop that ran through the ports enumerated by >>>>> CommPortIdentifier.getPortIdentifiers() >>>>> and there are only 2 of them: /dev/cu.modem and /dev/tty.modem >>>>> both of which are of "type 1" and have no "owner". >>>>> >>>>> The way you phrase your question leads me to believe there is >>>>> something notoriously obvious about cu.modem, but Google is not >>>>> making anything obvious for me. Please explain. >>>>> sj >>>>> >>>>> >>>>> On 2006 Sep 6, at 9:59 AM, Joachim Buechse wrote: >>>>> >>>>>> You are not by any chance using the cu.modem port? >>>>>> >>>>>> On 06.09.2006, at 15:26, Dr. Stephen Judd wrote: >>>>>> >>>>>>> I am trying to understand basic things about serial ports on the >>>>>>> Mac. >>>>>>> The SerialDemo.java program from Sun's javax.CommPort program >>>>>>> displays 2 panels: characters going out to a port, and characters >>>>>>> coming in from it. Question: if I have nothing attached to the >>>>>>> port, >>>>>>> why does anything get echoed from the outgoing panel to the >>>>>>> incoming >>>>>>> one? My mental model says nothing should happen until there is >>>>>>> some hardware attached to the port. >>>>>>> >>>>>>> Nothing I have looked for in the code tells me there is any >>>>>>> software >>>>>>> connection between the outgoing and incoming streams. >>>>>>> Please tell me what is broken in my brain. >>>>>>> sj >>>>> >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > From sjudd at seas.upenn.edu Mon Sep 11 17:10:44 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 19:10:44 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: AH! great. So my mental model was reasonable, but ahead of its time. Now how do I adjust my mental image? Does rebooting the machine change anything? How do I get to those new ports?! sj On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > > Hi Stephen > > The CommAPI 'specification' was written before ports could vanish and > appear. There isn't a means of catching 'hotplug' events yet. For > all > practical purposes, the hardware should not change while using CommAPI > 2.0. This shortfall has been discussed as a possible addition to > future > 'standards' which rxtx will support. For now, you have to adjust your > mental image :) > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >> >> Building on what I have learned from this group, my mental model has >> arrived at the point where I believe that the mere plugging in of >> a port >> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >> will automagically change the list of ports available to >> CommPortIdentifier.getPortIdentifiers(). >> >> Experiments say this is not true however. Using same SerialDemo as >> described below, the list does not change, even after plugging a >> live device >> into one of the resulting RS-232 ports, and restarting the app. >> >> What's broken now? my hardware? or still my head? >> sj >> >> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: From tjarvi at qbang.org Mon Sep 11 17:29:08 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Sep 2006 17:29:08 -0600 (MDT) Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi Stephen The kernel probably already does everything needed. Eventually, we will be receiving those events and sending events to applications that a device was plugged in. Depending upon the OS, either the kernel events are not detectable or rxtx ignores them at this time. Right now the commports are enumerated when RXTXCommDriver's static initialize is called. Thats usually the first 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in RXTXCommDriver.java. A small enhancement that many folks would like would be to allow rescanning of ports. Restarting the application after changing hardware is the usual path. Also consider that we do not currently make special efforts to deal with hardware vanishing. Whatever error you see after hardware is removed was not thought of as a flow control path for UARTs being ripped off the motherboard. It just wasn't something that happened. On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj > > On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From sjudd at seas.upenn.edu Mon Sep 11 19:38:38 2006 From: sjudd at seas.upenn.edu (Dr. Stephen Judd) Date: Mon, 11 Sep 2006 21:38:38 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Your comment about the kernel probably indicates you are discussing Linux. I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on plug and play. Can I get those ports to appear on the Mac? How? Do I have to use something other than RXTX to get there today? sj On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > Hi Stephen > > The kernel probably already does everything needed. Eventually, we > will > be receiving those events and sending events to applications that a > device > was plugged in. Depending upon the OS, either the kernel events are > not > detectable or rxtx ignores them at this time. > > Right now the commports are enumerated when RXTXCommDriver's static > initialize is called. Thats usually the first > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > RXTXCommDriver.java. A small enhancement that many folks would > like would > be to allow rescanning of ports. Restarting the application after > changing hardware is the usual path. Also consider that we do not > currently make special efforts to deal with hardware vanishing. > > Whatever error you see after hardware is removed was not thought of > as a > flow control path for UARTs being ripped off the motherboard. It just > wasn't something that happened. > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could vanish >>> and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to adjust >>> your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental model >>>> has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Bob_Jacobsen at lbl.gov Mon Sep 11 21:13:42 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Sep 2006 20:13:42 -0700 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: At 9:38 PM -0400 9/11/06, Dr. Stephen Judd wrote: >Your comment about the kernel probably indicates you are discussing >Linux. >I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on >plug and play. Can I get those ports to appear on the Mac? How? >Do I have to use something other than RXTX to get there today? You need to have the driver installed for whatever USB device you're using. Once that's done, plugging in the USB device will result in new entries in /dev/, that should be visible the next time you start your program. Rebooting, etc, should not be required. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From lyon at docjava.com Tue Sep 12 05:02:24 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 12 Sep 2006 07:02:24 -0400 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: Hi All, You know, dynamic USB updates seem like a good idea, to me. On the other hand, to add a PortIO USB to serial converter, I had to: 1. Download the latest driver, 2. Install the hardware, 3. Install the driver and 4. Reboot the system (this is part of the installer). Considering that USB should be hot pluggable, I am not sure why rebooting is required. What is going on here? Rebooting a UNIX system, for a USB addition, is typically rare, right? Does the specification on the Comm API have to change in order to accommodate the dynamic USB update? Thanks! - Doug >AH! great. >So my mental model was reasonable, but ahead of its time. >Now how do I adjust my mental image? Does rebooting the machine >change anything? How do I get to those new ports?! >sj > >On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> >> Hi Stephen >> >> The CommAPI 'specification' was written before ports could vanish and >> appear. There isn't a means of catching 'hotplug' events yet. For? >> all >> practical purposes, the hardware should not change while using CommAPI >> 2.0. This shortfall has been discussed as a possible addition to? >> future >> 'standards' which rxtx will support. For now, you have to adjust your >> mental image :) >> >> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >> >>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>> >>> Building on what I have learned from this group, my mental model has >>> arrived at the point where I believe that the mere plugging in of? >>> a port >>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter Cable) >>> will automagically change the list of ports available to >>> CommPortIdentifier.getPortIdentifiers(). >>> >>> Experiments say this is not true however. Using same SerialDemo as >>> described below, the list does not change, even after plugging a? >>> live device >>> into one of the resulting RS-232 ports, and restarting the app. >>> >>> What's broken now? my hardware? or still my head? >>> sj >>> >>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Sep 12 06:54:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 06:54:56 -0600 (MDT) Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: On Tue, 12 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > Hi Doug We would need to handle events. First RXTX would need to have a class that listened for the hotplug events. Linux, solaris (soon?) and Mac OS X should have such capability. Windows probably too but I've not seen how that works. This would involve native code at least on some OSs. Then the applications would need to implement a hotplug event listener or the API would just silently do it in the background. This has not really been defined yet. -- Trent Jarvi tjarvi at qbang.org From andy.dalton at gmail.com Tue Sep 12 06:57:14 2006 From: andy.dalton at gmail.com (Andy Dalton) Date: Tue, 12 Sep 2006 08:57:14 -0400 Subject: [Rxtx] loopback puzzle In-Reply-To: <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> References: <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> <9622063D-DC29-417E-9B2E-26CF70D0559A@seas.upenn.edu> Message-ID: <9b1737410609120557u7d8f6a0ej2cf714a3dfda3454@mail.gmail.com> One interim work-around (read 'hack') might be to do this externally to rxtx. There has been some talk about tying into hotplug functionality, but it might be easier to listen for file system modification events. You could watch /dev, and if an entry is created that matches what you're looking for as a serial port, call CommPortIdentifier.addPortName(...). If that worked, it'd only solve half the problem -- you still wouldn't be able to remove ports. I know Mac OSX shares the FreeBSD 'kqueue' API, which seems to be something similar to Linux's 'inotify' (or vice versa). There are Java APIs that wrap 'inotify' (see http://jnotify.sourceforge.net/), but I don't know if there are any for 'kqueue'. Andy On 9/11/06, Dr. Stephen Judd wrote: > Your comment about the kernel probably indicates you are discussing > Linux. > I'm running on Mac OSX 10.4.7, which traditionally has a big emphasis on > plug and play. Can I get those ports to appear on the Mac? How? > Do I have to use something other than RXTX to get there today? > sj > > On 2006 Sep 11, at 7:29 PM, Trent Jarvi wrote: > > > > > Hi Stephen > > > > The kernel probably already does everything needed. Eventually, we > > will > > be receiving those events and sending events to applications that a > > device > > was plugged in. Depending upon the OS, either the kernel events are > > not > > detectable or rxtx ignores them at this time. > > > > Right now the commports are enumerated when RXTXCommDriver's static > > initialize is called. Thats usually the first > > 'CommPortIdentifier.getPortIdentifiers();' thats called. This is in > > RXTXCommDriver.java. A small enhancement that many folks would > > like would > > be to allow rescanning of ports. Restarting the application after > > changing hardware is the usual path. Also consider that we do not > > currently make special efforts to deal with hardware vanishing. > > > > Whatever error you see after hardware is removed was not thought of > > as a > > flow control path for UARTs being ripped off the motherboard. It just > > wasn't something that happened. > > > > On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > > > >> AH! great. > >> So my mental model was reasonable, but ahead of its time. > >> Now how do I adjust my mental image? Does rebooting the machine > >> change anything? How do I get to those new ports?! > >> sj > >> > >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: > >> > >>> > >>> Hi Stephen > >>> > >>> The CommAPI 'specification' was written before ports could vanish > >>> and > >>> appear. There isn't a means of catching 'hotplug' events yet. For > >>> all > >>> practical purposes, the hardware should not change while using > >>> CommAPI > >>> 2.0. This shortfall has been discussed as a possible addition to > >>> future > >>> 'standards' which rxtx will support. For now, you have to adjust > >>> your > >>> mental image :) > >>> > >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: > >>> > >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. > >>>> > >>>> Building on what I have learned from this group, my mental model > >>>> has > >>>> arrived at the point where I believe that the mere plugging in of > >>>> a port > >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter > >>>> Cable) > >>>> will automagically change the list of ports available to > >>>> CommPortIdentifier.getPortIdentifiers(). > >>>> > >>>> Experiments say this is not true however. Using same SerialDemo as > >>>> described below, the list does not change, even after plugging a > >>>> live device > >>>> into one of the resulting RS-232 ports, and restarting the app. > >>>> > >>>> What's broken now? my hardware? or still my head? > >>>> sj > >>>> > >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tod at todbot.com Tue Sep 12 10:50:50 2006 From: tod at todbot.com (Tod E. Kurt) Date: Tue, 12 Sep 2006 09:50:50 -0700 Subject: [Rxtx] dynamic usb updates In-Reply-To: References: <6E3AF6DF-343C-4C6D-B741-BB15D8F55DA4@buechse.de> <80394749-40FC-43CF-8DDF-898AE71E87FA@seas.upenn.edu> <3B974316-DB62-47F4-8B85-C7C4B3EFEBBE@buechse.de> <9EC17E21-5CDB-4BF6-B952-6BAF728BDC51@seas.upenn.edu> <58705067-8342-4E2F-8EA1-4F63756B4E75@seas.upenn.edu> Message-ID: <9C535F7D-FADD-4F85-A251-E195D3135652@todbot.com> Re: why a reboot needed when adding USB serial devices. On both Linux and Mac OS X, it's possible to start using a new device driver immediately, using 'modprobe' or 'kextload', respectively. So you could install the driver, then use one of those programs to avoid a reboot. For instance, on Mac OS X, you can load a newly installed serial driver for the FTDI chip by doing: sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext Th problem (at least for Mac OS X, I'm not entire up on how Linux does it), is that the USB hotplug kernel module 'IOUSBFamily.kext' only scans for potential drivers to use on startup. The Linux 'hotplug' daemon performs a similar role I think. You may be able to do a 'kextunload' and 'kextload' on IOUSBFamily to get it to rescan the driver list, but I've not tried it. For devices that conform to USB device class standard, like HID, audio, mass storage, etc. no new drivers are required so adding new devices of those class Just Work. -=tod On Sep 12, 2006, at 4:02 AM, Dr. Douglas Lyon wrote: > Hi All, > You know, dynamic USB updates seem like a good idea, to me. > On the other hand, to add a PortIO USB to serial converter, > I had to: > 1. Download the latest driver, > 2. Install the hardware, > 3. Install the driver and > 4. Reboot the system (this is part of the installer). > > Considering that USB should be hot pluggable, I am not > sure why rebooting is required. What is going on here? > > Rebooting a UNIX system, for a USB addition, is typically rare, right? > > Does the specification on the Comm API have to change in order > to accommodate the dynamic USB update? > > Thanks! > - Doug > >> AH! great. >> So my mental model was reasonable, but ahead of its time. >> Now how do I adjust my mental image? Does rebooting the machine >> change anything? How do I get to those new ports?! >> sj >> >> On 2006 Sep 11, at 7:00 PM, Trent Jarvi wrote: >> >>> >>> Hi Stephen >>> >>> The CommAPI 'specification' was written before ports could >>> vanish and >>> appear. There isn't a means of catching 'hotplug' events yet. For >>> all >>> practical purposes, the hardware should not change while using >>> CommAPI >>> 2.0. This shortfall has been discussed as a possible addition to >>> future >>> 'standards' which rxtx will support. For now, you have to >>> adjust your >>> mental image :) >>> >>> On Mon, 11 Sep 2006, Dr. Stephen Judd wrote: >>> >>>> Many thanks to Dr. Lyon, Joachim Buechse, and Bob Jacobsen. >>>> >>>> Building on what I have learned from this group, my mental >>>> model has >>>> arrived at the point where I believe that the mere plugging in of >>>> a port >>>> expander (like the DUAL PORT USB to Serial RS-232 DB-9 Adapter >>>> Cable) >>>> will automagically change the list of ports available to >>>> CommPortIdentifier.getPortIdentifiers(). >>>> >>>> Experiments say this is not true however. Using same SerialDemo as >>>> described below, the list does not change, even after plugging a >>>> live device >>>> into one of the resulting RS-232 ports, and restarting the app. >>>> >>>> What's broken now? my hardware? or still my head? >>>> sj >>>> >>>> On 2006 Sep 7, at 8:40 AM, Dr. Douglas Lyon wrote: >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From smontgomery at mediaspansoftware.com Tue Sep 12 17:05:21 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Tue, 12 Sep 2006 19:05:21 -0400 Subject: [Rxtx] RXTX cvs access? Message-ID: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> I was just trying to access the RXTX source via cvs on my Mac (OS X 10.4.7, via the Bash shell in Terminal) using the instructions at: http://www.rxtx.org/cvs.html Followed to the letter (including the rodent-oriented password). It appears that I can reach the server since I get a password request but once I enter the password nothing happens for a while, then I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Operation timed out Has anybody been able to access cvs lately? Do I need to know some special handshake or something ;-) I'm trying to get ahold of the 2.0.7 release for OS X (or later, whatever will let me build 2.0.x Universal Binaries) but the best I can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm trying to get to the source via cvs. From tjarvi at qbang.org Tue Sep 12 19:04:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 12 Sep 2006 19:04:28 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: On Tue, 12 Sep 2006, Sean Montgomery wrote: > I was just trying to access the RXTX source via cvs on my Mac (OS X > 10.4.7, via the Bash shell in Terminal) using the instructions at: > > http://www.rxtx.org/cvs.html > > Followed to the letter (including the rodent-oriented password). It > appears that I can reach the server since I get a password request > but once I enter the password nothing happens for a while, then I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Operation timed out > > Has anybody been able to access cvs lately? Do I need to know some > special handshake or something ;-) > > I'm trying to get ahold of the 2.0.7 release for OS X (or later, > whatever will let me build 2.0.x Universal Binaries) but the best I > can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm > trying to get to the source via cvs. Hi Sean It looks like Ken is having some problems with his server. It can't have been down long. Lets let him have some time to get it back up. I'd email him but it goes to the same IP which is not working at the moment. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Wed Sep 13 11:09:02 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 13 Sep 2006 13:09:02 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Ok, so it's not just me ;-) Looks like it's still down right now. May I make a small appeal to the Mac RXTX community, if anybody has a set of Universal Binary RXTX 2.0.7/.8 installables that they post it to the Wiki or put it on the ftp site at qbang? Since the only thing I guess I'd actually need would be a UB librxtxSerial.jnilib maybe somebody could just zip it and mail me a copy? Thanks, and my apologies for the "gimme", Sean On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > On Tue, 12 Sep 2006, Sean Montgomery wrote: > >> I was just trying to access the RXTX source via cvs on my Mac (OS X >> 10.4.7, via the Bash shell in Terminal) using the instructions at: >> >> http://www.rxtx.org/cvs.html >> >> Followed to the letter (including the rodent-oriented password). It >> appears that I can reach the server since I get a password request >> but once I enter the password nothing happens for a while, then I >> get: >> >> cvs [login aborted]: connect to cvs.milestonesolutions.com >> (208.2.190.117):2401 failed: Operation timed out >> >> Has anybody been able to access cvs lately? Do I need to know some >> special handshake or something ;-) >> >> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >> whatever will let me build 2.0.x Universal Binaries) but the best I >> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >> trying to get to the source via cvs. > > Hi Sean > > It looks like Ken is having some problems with his server. It > can't have > been down long. Lets let him have some time to get it back up. > I'd email > him but it goes to the same IP which is not working at the moment. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Thu Sep 14 07:24:08 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 14 Sep 2006 09:24:08 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: Uh, just tried to access cvs again just now, still timing out at cvs login... I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS X) support. Any suggestions on where I can access the binaries and/ or source? I'm hoping I'm just being stupid and missing the obvious here... please feel free to educate me :-P Thanks again, Sean On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > Ok, so it's not just me ;-) > > Looks like it's still down right now. May I make a small appeal to > the Mac RXTX community, if anybody has a set of Universal Binary RXTX > 2.0.7/.8 installables that they post it to the Wiki or put it on the > ftp site at qbang? > > Since the only thing I guess I'd actually need would be a UB > librxtxSerial.jnilib maybe somebody could just zip it and mail me a > copy? > > Thanks, and my apologies for the "gimme", > > Sean > > On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: > >> On Tue, 12 Sep 2006, Sean Montgomery wrote: >> >>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>> >>> http://www.rxtx.org/cvs.html >>> >>> Followed to the letter (including the rodent-oriented password). It >>> appears that I can reach the server since I get a password request >>> but once I enter the password nothing happens for a while, then I >>> get: >>> >>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>> (208.2.190.117):2401 failed: Operation timed out >>> >>> Has anybody been able to access cvs lately? Do I need to know some >>> special handshake or something ;-) >>> >>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>> whatever will let me build 2.0.x Universal Binaries) but the best I >>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>> trying to get to the source via cvs. >> >> Hi Sean >> >> It looks like Ken is having some problems with his server. It >> can't have >> been down long. Lets let him have some time to get it back up. >> I'd email >> him but it goes to the same IP which is not working at the moment. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 14 21:08:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Sep 2006 21:08:16 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: I did get an email back from Ken. Hementionedproblemswith the NOC and said it should be back up this weekend. I'd just give you what I have on my laptop for 2.0 but I'd rather wait. I may have messed with the code since commiting to CVS. We need to tag the code for 2.0 and change the version number but what is in CVS should be up to date. If someone wants to work with me this weekend and build the Mac OS X version, we can release it on the rxtx download page. I expect to be building Mac OS X this fall also but don't have that setup yet. On Thu, 14 Sep 2006, Sean Montgomery wrote: > Uh, just tried to access cvs again just now, still timing out at cvs > login... > > I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS > X) support. Any suggestions on where I can access the binaries and/ > or source? I'm hoping I'm just being stupid and missing the obvious > here... please feel free to educate me :-P > > Thanks again, > > Sean > > On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: > >> Ok, so it's not just me ;-) >> >> Looks like it's still down right now. May I make a small appeal to >> the Mac RXTX community, if anybody has a set of Universal Binary RXTX >> 2.0.7/.8 installables that they post it to the Wiki or put it on the >> ftp site at qbang? >> >> Since the only thing I guess I'd actually need would be a UB >> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >> copy? >> >> Thanks, and my apologies for the "gimme", >> >> Sean >> >> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >> >>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>> >>>> I was just trying to access the RXTX source via cvs on my Mac (OS X >>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>> >>>> http://www.rxtx.org/cvs.html >>>> >>>> Followed to the letter (including the rodent-oriented password). It >>>> appears that I can reach the server since I get a password request >>>> but once I enter the password nothing happens for a while, then I >>>> get: >>>> >>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>> (208.2.190.117):2401 failed: Operation timed out >>>> >>>> Has anybody been able to access cvs lately? Do I need to know some >>>> special handshake or something ;-) >>>> >>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>> whatever will let me build 2.0.x Universal Binaries) but the best I >>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence I'm >>>> trying to get to the source via cvs. >>> >>> Hi Sean >>> >>> It looks like Ken is having some problems with his server. It >>> can't have >>> been down long. Lets let him have some time to get it back up. >>> I'd email >>> him but it goes to the same IP which is not working at the moment. >>> >>> -- >>> Trent Jarvi >>> tjarvi at qbang.org >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Bob_Jacobsen at lbl.gov Thu Sep 14 22:02:37 2006 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Thu, 14 Sep 2006 21:02:37 -0700 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >Uh, just tried to access cvs again just now, still timing out at cvs >login... > >I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >X) support. Any suggestions on where I can access the binaries and/ >or source? I'm hoping I'm just being stupid and missing the obvious >here... please feel free to educate me :-P There's an installer at Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From smontgomery at mediaspansoftware.com Fri Sep 15 07:23:39 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:23:39 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <68C3C122-13B3-46A2-A322-CA6A4287F7EB@mediaspansoftware.com> Thanks for the info, Trent, and thanks to Ken, too. On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From smontgomery at mediaspansoftware.com Fri Sep 15 07:43:45 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Fri, 15 Sep 2006 09:43:45 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <4175CEFD-1678-4ADB-A21B-C253E08191A5@mediaspansoftware.com> Thanks Bob, that's a great help! On Sep 15, 2006, at 12:02 AM, Bob Jacobsen wrote: > At 9:24 AM -0400 9/14/06, Sean Montgomery wrote: >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P > > There's an installer at > > download> > > Bob > -- > Bob Jacobsen, UC Berkeley > jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, > Skype JacobsenRG > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From npapadop at inaccessnetworks.com Fri Sep 15 09:40:57 2006 From: npapadop at inaccessnetworks.com (Nektarios K. Papadopoulos) Date: Fri, 15 Sep 2006 18:40:57 +0300 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <450AC989.5020004@inaccessnetworks.com> Trent Jarvi wrote: > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. I guess the tagging/version number process is not Mac OS X specific, right? I'd also like a 2.0.7 final source download. I can't find one on the ftp server. Could you also consider fixing bug 64[1] ? It is trivial and quite disturbing. I've just added a patch against rxtx-2.1-7r2. I could provide a patch for 2.0 if CVS was available ;-) cheers, nek [1] http://bugzilla.qbang.org/show_bug.cgi?id=64 -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ From yvespielusenet at free.fr Mon Sep 18 07:28:22 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 15:28:22 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <1158586103.5586.12.camel@localhost.localdomain> Hello, I was using the Parport library to read parallel port status. http://www.geocities.com/Juanga69/parport/ I did something like parport.read() which gives me a byte. I use this to get a printer status. I don't want to use parport anymore since it doesn't work with XP without the Userport programme. How can I do this with rxtx ? I want to read all parallel status pin from my programme. I'm searching but I can't find any exemple :( thanks in advance :) -- yves piel From ajmas at sympatico.ca Mon Sep 18 10:51:04 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 12:51:04 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, I have never had to deal with parallel ports myself, though there are a couple of examples here: http://rxtx.qbang.org/wiki/index.php/Examples If you look at the first example, which is for a serial port, as a basis, then at the line where the the following test is done: commPort instanceof SerialPort modify it to test to see if commPort is an instance of ParallelPort and then cast it to ParallelPort. The API specification is here: http://java.sun.com/products/javacomm/reference/api/index.html Hope this helps. Andre yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > -- > yves piel > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Mon Sep 18 12:41:09 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 18 Sep 2006 14:41:09 -0400 Subject: [Rxtx] loopback puzzle Message-ID: <20060918184109.NWIX1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Dr. Stephen Judd wrote: > > AH! great. > So my mental model was reasonable, but ahead of its time. > Now how do I adjust my mental image? Does rebooting the machine > change anything? How do I get to those new ports?! > sj In most modern operating systems a reboot should not be necessary to recognise these ports, especially if the ports correspond to a USB device. The logic here is that USB devices are usually managed in 'user-space', with the kernel only providing the link. For the reasons mentioned above a restart of the application is enough to see the new ports. Using Bluetooth GPS and USB serial ports myself with MacOS X and Windows XP shows that this is indeed the case. Where I have issues is trying to add two serial adaptors under Windows XP, though I am not sure whether it is an WinXP issue or the driver which can't support two devices with the same manufacturer/device id ( in my case FT232BM ). Changing the Java Comm API to be dynamic would reduce the need even for an applicationr restart - I don't talk about eliminating, since there are drivers out there that have strange requirements. Andre From yvespielusenet at free.fr Mon Sep 18 13:27:13 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 18 Sep 2006 21:27:13 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060918165104.ZAJR27612.tomts16-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <1158607634.5586.20.camel@localhost.localdomain> thanks :) I have tried to read parport so. I modified SimpleRead.java from the exemple directory of javax.comm API. I change it to use rxtx, and change SerialPort for ParallelPort. than I remove the event since it didn't work And I o the Thread : -------------------------------- run(){ try{ InputStream is = this.parallelport.get while(true){ System.out.println("=>"+is.read()); } } catch(Exception e){ System.out.println("error : "+e); } } --------------------------- When I do this under windows XP I have this error : --------------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. ---------------------------------------------------------- (Fonction incorrecte means bad function) What is this error ? thanks Le lundi 18 septembre 2006 ? 12:51 -0400, Andre-John Mas a ?crit : > Hi, > > I have never had to deal with parallel ports myself, though there > are a couple of examples here: > > http://rxtx.qbang.org/wiki/index.php/Examples > > If you look at the first example, which is for a serial port, as > a basis, then at the line where the the following test is done: > > commPort instanceof SerialPort > > modify it to test to see if commPort is an instance of ParallelPort > and then cast it to ParallelPort. The API specification is here: > > http://java.sun.com/products/javacomm/reference/api/index.html > > Hope this helps. > > Andre > > > yves pielusenet wrote: > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > -- > > yves piel > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Mon Sep 18 22:07:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 18 Sep 2006 22:07:05 -0600 (MDT) Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: <1158586103.5586.12.camel@localhost.localdomain> References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: On Mon, 18 Sep 2006, yves pielusenet wrote: > > Hello, > I was using the Parport library to read parallel port status. > http://www.geocities.com/Juanga69/parport/ > I did something like parport.read() which gives me a byte. > I use this to get a printer status. > I don't want to use parport anymore since it doesn't work with XP > without the Userport programme. > > How can I do this with rxtx ? I want to read all parallel status pin > from my programme. > > I'm searching but I can't find any exemple :( > > thanks in advance :) > > Which version of rxtx are you trying? There appears to e support for the things you want. The parallel support is much less mature than the serial support but has worked for people. public abstract boolean isPaperOut(); public abstract boolean isPrinterBusy(); public abstract boolean isPrinterError(); public abstract boolean isPrinterSelected(); public abstract boolean isPrinterTimedOut(); These are what you are after, right? The read error looks like maybe a bad native lib? We do very little testing on those. If it is current rxtx, we can take a look. -- Trent Jarvi tjarvi at qbang.org From yvespielusenet at free.fr Tue Sep 19 01:59:42 2006 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 19 Sep 2006 09:59:42 +0200 Subject: [Rxtx] [PARALLELPORT] read parallel port status In-Reply-To: References: <1158586103.5586.12.camel@localhost.localdomain> Message-ID: <1158652782.6501.12.camel@localhost.localdomain> > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); It's not sure that what's I searched for. In fact, we have added an optical device on the printer which change on of the parallel port pin value in certain conditions. I can't remember on which pin this compenent is attached (I think it's paperEmpty but I'm not sure). I have just tried 'isPaperOut()' and it's works well :) I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same directory of SimpleRead.class. To have a device behind the parallelPort I have plug a parallel IOmega ZIP 100Mo. Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this error for each parallelPort.getInputStream().read() : --------------------------------------------------- ERROR : java.io.IOException: Fonction incorrecte. in readByte Error 0x1 at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): Fonction incorrecte. --------------------------------------------------- Here is the class I tested : ------------------------------------------------------------------------------ /* * @(#)SimpleRead.java 1.12 98/06/25 SMI * * Copyright 2003 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * Sun grants you ("Licensee") a non-exclusive, royalty free, license * to use, modify and redistribute this software in source and binary * code form, provided that i) this copyright notice and license appear * on all copies of the software; and ii) Licensee does not utilize the * software in a manner which is disparaging to Sun. * * This software is provided "AS IS," without a warranty of any kind. * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * This software is not designed or intended for use in on-line control * of aircraft, air traffic, aircraft navigation or aircraft * communications; or in the design, construction, operation or * maintenance of any nuclear facility. Licensee represents and * warrants that it will not use or redistribute the Software for such * purposes. */ import java.io.*; import java.util.*; import gnu.io.*; public class SimpleRead implements Runnable, ParallelPortEventListener { static CommPortIdentifier portId; static Enumeration portList; InputStream inputStream; ParallelPort parallelPort; Thread readThread; /** * Method declaration * * * @param args * * @see */ public static void main(String[] args) { boolean portFound = false; String defaultPort = "LPT1"; if (args.length > 0) { defaultPort = args[0]; } portList = CommPortIdentifier.getPortIdentifiers(); while (portList.hasMoreElements()) { portId = (CommPortIdentifier) portList.nextElement(); if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { if (portId.getName().equals(defaultPort)) { System.out.println("Found port: "+defaultPort); portFound = true; SimpleRead reader = new SimpleRead(); } } } if (!portFound) { System.out.println("port " + defaultPort + " not found."); } } public SimpleRead() { try { parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); } catch (PortInUseException e) {} try { inputStream = parallelPort.getInputStream(); } catch (IOException e) {} /*try { parallelPort.addEventListener(this); } catch (TooManyListenersException e) {}*/ readThread = new Thread(this); readThread.start(); } public void run() { try{ InputStream is = this.parallelPort.getInputStream(); while(true){ try{ System.out.println("=>"+is.read()); } catch(Exception e){ System.out.println("ERROR : "+e); } } } catch(Exception e){ System.out.println("ERREUR : "+e); } } /** * Method declaration * * * @param event * * @see */ public void parallelEvent(ParallelPortEvent event) { } } --------------------------------------------------------------------------------------- Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > Hello, > > I was using the Parport library to read parallel port status. > > http://www.geocities.com/Juanga69/parport/ > > I did something like parport.read() which gives me a byte. > > I use this to get a printer status. > > I don't want to use parport anymore since it doesn't work with XP > > without the Userport programme. > > > > How can I do this with rxtx ? I want to read all parallel status pin > > from my programme. > > > > I'm searching but I can't find any exemple :( > > > > thanks in advance :) > > > > > > Which version of rxtx are you trying? There appears to e support for the > things you want. The parallel support is much less mature than the serial > support but has worked for people. > > public abstract boolean isPaperOut(); > public abstract boolean isPrinterBusy(); > public abstract boolean isPrinterError(); > public abstract boolean isPrinterSelected(); > public abstract boolean isPrinterTimedOut(); > > These are what you are after, right? > > The read error looks like maybe a bad native lib? We do very little > testing on those. If it is current rxtx, we can take a look. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Tue Sep 19 10:31:13 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Tue, 19 Sep 2006 12:31:13 -0400 Subject: [Rxtx] [PARALLELPORT] read parallel port status Message-ID: <20060919163113.ZNCY1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Looking at the source, the line referenced by the error: /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517) corresponds to the call to YACK(), for the context: #if defined(WIN32) if(!ReadFile( (HANDLE)fd, buffer + bytes, left, (DWORD *)&ret, NULL )){ YACK(); ret = -1; } The function YACK() is defined in win32termios.h. I am not sure exactly what a 'bad function' is, but I wonder why the function is defined using a macro, rather than just plain C? Andre > I downloaded rxtx-2.1-7-bins-r2.zip from the site. I copied > RXTXcomm.jar, rxtxParallel.dll and rxtxSerial.dll into the same > directory of SimpleRead.class. To have a device behind the parallelPort > I have plug a parallel IOmega ZIP 100Mo. > Then I launched 'java -cp RXTXcomm.jar;. SimpleRead' and I have this > error for each parallelPort.getInputStream().read() : > --------------------------------------------------- > ERROR : java.io.IOException: Fonction incorrecte. > in readByte > Error 0x1 > at /home/bob/foo/tar/rxtx-2.1-7/build/../src/ParallelImp.c(517): > Fonction incorrecte. > --------------------------------------------------- > Here is the class I tested : > ------------------------------------------------------------------------------ > /* > * @(#)SimpleRead.java 1.12 98/06/25 SMI > * > * Copyright 2003 Sun Microsystems, Inc. All rights reserved. > * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > * > * Sun grants you ("Licensee") a non-exclusive, royalty free, license > * to use, modify and redistribute this software in source and binary > * code form, provided that i) this copyright notice and license appear > * on all copies of the software; and ii) Licensee does not utilize the > * software in a manner which is disparaging to Sun. > * > * This software is provided "AS IS," without a warranty of any kind. > * ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, > * INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A > * PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND > * ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY > * LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE > * SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS > * BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, > * INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, > * HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING > * OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN > * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. > * > * This software is not designed or intended for use in on-line control > * of aircraft, air traffic, aircraft navigation or aircraft > * communications; or in the design, construction, operation or > * maintenance of any nuclear facility. Licensee represents and > * warrants that it will not use or redistribute the Software for such > * purposes. > */ > import java.io.*; > import java.util.*; > import gnu.io.*; > > public class SimpleRead implements Runnable, ParallelPortEventListener { > static CommPortIdentifier portId; > static Enumeration portList; > InputStream inputStream; > ParallelPort parallelPort; > Thread readThread; > > /** > * Method declaration > * > * > * @param args > * > * @see > */ > public static void main(String[] args) { > boolean portFound = false; > String defaultPort = "LPT1"; > > if (args.length > 0) { > defaultPort = args[0]; > } > > portList = CommPortIdentifier.getPortIdentifiers(); > > while (portList.hasMoreElements()) { > portId = (CommPortIdentifier) portList.nextElement(); > if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { > if (portId.getName().equals(defaultPort)) { > System.out.println("Found port: "+defaultPort); > portFound = true; > SimpleRead reader = new SimpleRead(); > } > } > } > if (!portFound) { > System.out.println("port " + defaultPort + " not found."); > } > > } > > public SimpleRead() { > try { > parallelPort = (ParallelPort) portId.open("SimpleReadApp", 2000); > } catch (PortInUseException e) {} > > try { > inputStream = parallelPort.getInputStream(); > } catch (IOException e) {} > > /*try { > parallelPort.addEventListener(this); > } catch (TooManyListenersException e) {}*/ > > readThread = new Thread(this); > > readThread.start(); > } > > public void run() { > try{ > InputStream is = this.parallelPort.getInputStream(); > while(true){ > try{ > System.out.println("=>"+is.read()); > } > catch(Exception e){ > System.out.println("ERROR : "+e); > } > } > } > catch(Exception e){ > System.out.println("ERREUR : "+e); > } > } > > /** > * Method declaration > * > * > * @param event > * > * @see > */ > public void parallelEvent(ParallelPortEvent event) { > } > > } > --------------------------------------------------------------------------------------- > > Le lundi 18 septembre 2006 ? 22:07 -0600, Trent Jarvi a ?crit : > > On Mon, 18 Sep 2006, yves pielusenet wrote: > > > > > > > > Hello, > > > I was using the Parport library to read parallel port status. > > > http://www.geocities.com/Juanga69/parport/ > > > I did something like parport.read() which gives me a byte. > > > I use this to get a printer status. > > > I don't want to use parport anymore since it doesn't work with XP > > > without the Userport programme. > > > > > > How can I do this with rxtx ? I want to read all parallel status pin > > > from my programme. > > > > > > I'm searching but I can't find any exemple :( > > > > > > thanks in advance :) > > > > > > > > > > Which version of rxtx are you trying? There appears to e support for the > > things you want. The parallel support is much less mature than the serial > > support but has worked for people. > > > > public abstract boolean isPaperOut(); > > public abstract boolean isPrinterBusy(); > > public abstract boolean isPrinterError(); > > public abstract boolean isPrinterSelected(); > > public abstract boolean isPrinterTimedOut(); > > > > These are what you are after, right? > > > > The read error looks like maybe a bad native lib? We do very little > > testing on those. If it is current rxtx, we can take a look. > > > > -- > > Trent Jarvi > > tjarvi at qbang.org > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pete.flugstad at gmail.com Tue Sep 19 10:10:39 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Tue, 19 Sep 2006 11:10:39 -0500 Subject: [Rxtx] RTS control in RXTX Message-ID: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> So, it seems like there are basically two more or less incompatible ways to handle the RTS line: - "old" style: RTS held low until PC ready to TX, then raised - classic Request To Send behavior - CTS is then raised by the modem to do PC->modem flow control - "new" style: RTS held high indicating PC is ready to RX - newer "Request to Send to me" behavior, used for modem->PC flow control Right now, RXTX selects the new behavior, and seems to assumes the whole process is handled automatically the by the device driver (I think, I haven't dug into it). There's no way to access the "old" style behavior (at least on Windows) without modifying the RXTX source code and rebuilding. It seems that RXTX (and the javax comm API) can't really deal with this difference, even if the underlying OS (e.g. Windows) allows access to both behaviors. This would seem to partly be a shortcoming of the termios interface, which the javax comm API seems to have been based on (makes sense given it came from Sun), but I don't know termios very well, so I can't say for sure. So the next question is: what would people think would be the best way to extend the javax.com (aka gnu.io) API to allow an application program access to whichever behavior they want? I don't want (and literlly can't since they will likely get pulled into the same JVM) to have multiple versions of RXTX around. My initial thought was to actually modify RXTX to start paying attention to the IN/OUT HW flow control values - I think right now, it just maps either to enabling both direction of HW flow control. My mod would change it so that RTSCTS_OUT by itself would turn on the old behavior, whle RTSCTS_OUT|IN would turn on the new behavior. Then there's the whole DTR/DSR behavior as well, which RXTX seems to require a more or less manual intervention by whatever application wants to use it. Anyway, I haven't thought much beyond all this. I wanted to get the groups feedback so that I don't paint myself into a corner. Has anyone else seen any other Java Serial Port implementations that do something like this (like one of the commercial ones?). Anyone have any other suggestions? Thanks, Pete From smontgomery at mediaspansoftware.com Wed Sep 20 13:18:47 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Wed, 20 Sep 2006 15:18:47 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? Message-ID: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> I've looked through the mailing list to see if something like this has already been discussed, but I didn't notice anything. Perhaps somebody might have seen something similar. I've got RXTX 2.0.7 final Universal Binary installed on an Intel single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X serial adapter attached and Keyspan's 2.2 drivers are loaded (that's their latest Universal Binary drivers). I'm running a Java app using Java 1.4.2 that opens one of the Keyspan serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS flowcontrol. I also call enableReceiveTimout(500) so that reads won't block forever. I don't write to the port, I only read. This works fine on all other machines I've tested, PPC and Intel. On this particular box when we attempt to close the serial port the JVM crashes. Here's the appropriate bit of the stack trace: Thread 17 Crashed: 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 1 librxtxSerial.jnilib 0x05fdd18f Java_gnu_io_RXTXPort_interruptEventLoop + 293 2 <<00000000>> 0x03f36c4b 0 + 66284619 3 <<00000000>> 0x03f31bc3 0 + 66264003 4 <<00000000>> 0x03f31bc3 0 + 66264003 5 <<00000000>> 0x03f31bc3 0 + 66264003 6 <<00000000>> 0x03f31bc3 0 + 66264003 7 <<00000000>> 0x03f31bc3 0 + 66264003 8 <<00000000>> 0x03f2f0ed 0 + 66253037 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 So it looks like a 2.0.7 Universal Library on Intel issue. If anybody has any ideas or if closing ports, interrupt event loops and crashes ring any bells, please let me know :-) Thanks, Sean P.S. The machine in question is several time zones away so I haven't been able to fire the app up in the debugger. From tjarvi at qbang.org Wed Sep 20 20:37:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 20:37:22 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: > It seems that RXTX (and the javax comm API) can't really deal with > this difference, even if the underlying OS (e.g. Windows) allows > access to both behaviors. This would seem to partly be a shortcoming > of the termios interface, which the javax comm API seems to have been > based on (makes sense given it came from Sun), but I don't know > termios very well, so I can't say for sure. > > So the next question is: what would people think would be the best way > to extend the javax.com (aka gnu.io) API to allow an application > program access to whichever behavior they want? I don't want (and > literlly can't since they will likely get pulled into the same JVM) to > have multiple versions of RXTX around. > > My initial thought was to actually modify RXTX to start paying > attention to the IN/OUT HW flow control values - I think right now, it > just maps either to enabling both direction of HW flow control. My > mod would change it so that RTSCTS_OUT by itself would turn on the old > behavior, whle RTSCTS_OUT|IN would turn on the new behavior. > > Then there's the whole DTR/DSR behavior as well, which RXTX seems to > require a more or less manual intervention by whatever application > wants to use it. > > Anyway, I haven't thought much beyond all this. I wanted to get the > groups feedback so that I don't paint myself into a corner. Has > anyone else seen any other Java Serial Port implementations that do > something like this (like one of the commercial ones?). Anyone have > any other suggestions? Hi Pete, My concern is mainly platform neutrality. We can do some of this but other parts are very MSFT Windows specific. I suspect that commapi had a Windows developer involved early on based upon some of the functionality already in the API. How much of this is just trying to fit as much of the Windows API in as possible vs known usage cases? If there are usage cases and Unix just can't do it, thats one thing vs advertising features which are just really obscure corner cases at best alongside what everyone uses. It is possible to work through much of this. There are folks looking at an API update [under NDA now?]. -- Trent Jarvi tjarvi at qbang.org From pete.flugstad at gmail.com Wed Sep 20 21:44:48 2006 From: pete.flugstad at gmail.com (Pete Flugstad) Date: Wed, 20 Sep 2006 22:44:48 -0500 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> Message-ID: <45120AB0.2040508@gmail.com> Trent Jarvi wrote: > My concern is mainly platform neutrality. We can do some of this but > other parts are very MSFT Windows specific. I suspect that commapi had a > Windows developer involved early on based upon some of the functionality > already in the API. > > How much of this is just trying to fit as much of the Windows API in as > possible vs known usage cases? If there are usage cases and Unix just > can't do it, thats one thing vs advertising features which are just really > obscure corner cases at best alongside what everyone uses. I don't especially care about what Windows is doing - we would like to be cross platfor as much as possible. But it does appear to me that the Windows API encompasses all various behaviors (the two RTS behaviors, CTS behavior, DTR/DSR behavior) that are currently being used with standard RS232 hardware. And I think it would be best for the javacomm API if it exposed this functionality, even if not all platforms implemented them. As other posters in my original thread have noted, both RTS behaviors are fairly common. Right now, on the Windows platform, you literally cannot get the old style RTS/CTS (i.e. flow control only in PC->Modem) behavior without modifying RXTX - other platforms are probably going to have the same problem (unfortunately). In any case, I'm basically just rattling the cage here - I'm really just interested in doing enough to get RXTX working for our projects - I could conceivably do something totally custom to us (recognizing the RXTX license of course) but then if we ever wanted to move onto newer RXTX or another javacomm impl, we'd be in trouble, which I'd like to avoid. So, consider the cage rattled (Bob Jacobsen, Guillermo Rodriguez Garcia, et al) :-). > It is possible to work through much of this. There are folks looking at > an API update [under NDA now?]. Do you mean that there are people doing this (and they're under NDA), or are you asking the question? If you're asking the question; I have no idea. Pete From tjarvi at qbang.org Wed Sep 20 22:04:43 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 20 Sep 2006 22:04:43 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <45120AB0.2040508@gmail.com> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: On Wed, 20 Sep 2006, Pete Flugstad wrote: >> It is possible to work through much of this. There are folks looking at >> an API update [under NDA now?]. > > Do you mean that there are people doing this (and they're under NDA), or > are you asking the question? If you're asking the question; I have no idea. Hi Pete We [rxtx] expressed interest in working towards a JSR. Doug mentioned that he would take a look and later mentioned in email that there is an NDA. Thats all I know at this time. -- Trent Jarvi tjarvi at qbang.org From joachim at buechse.de Thu Sep 21 02:31:25 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 21 Sep 2006 10:31:25 +0200 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> Message-ID: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> I have seen the same kind of crashes as well, albeit on PPC. This is due to the fact, that the event_info_struct gets damaged during the closing of the port. Which leads to the fact that the closing flag gets overwritten by some weird value, which again leads to the call to pthread_cancel (normally this should never be called). I have posted this some weeks ago, but nobody was able to reproduce it. I think I also filed in on Bugzilla. Best regard, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 20.09.2006, at 21:18, Sean Montgomery wrote: > I've looked through the mailing list to see if something like this > has already been discussed, but I didn't notice anything. Perhaps > somebody might have seen something similar. > > I've got RXTX 2.0.7 final Universal Binary installed on an Intel > single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X > serial adapter attached and Keyspan's 2.2 drivers are loaded (that's > their latest Universal Binary drivers). > > I'm running a Java app using Java 1.4.2 that opens one of the Keyspan > serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS > flowcontrol. I also call enableReceiveTimout(500) so that reads > won't block forever. I don't write to the port, I only read. > > This works fine on all other machines I've tested, PPC and Intel. On > this particular box when we attempt to close the serial port the JVM > crashes. Here's the appropriate bit of the stack trace: > > Thread 17 Crashed: > 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 > 1 librxtxSerial.jnilib 0x05fdd18f > Java_gnu_io_RXTXPort_interruptEventLoop + 293 > 2 <<00000000>> 0x03f36c4b 0 + 66284619 > 3 <<00000000>> 0x03f31bc3 0 + 66264003 > 4 <<00000000>> 0x03f31bc3 0 + 66264003 > 5 <<00000000>> 0x03f31bc3 0 + 66264003 > 6 <<00000000>> 0x03f31bc3 0 + 66264003 > 7 <<00000000>> 0x03f31bc3 0 + 66264003 > 8 <<00000000>> 0x03f2f0ed 0 + 66253037 > 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 > 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 > 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 > 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 > 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 > 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + 34773 > 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 > > So it looks like a 2.0.7 Universal Library on Intel issue. If > anybody has any ideas or if closing ports, interrupt event loops and > crashes ring any bells, please let me know :-) > > Thanks, > > Sean > > P.S. The machine in question is several time zones away so I haven't > been able to fire the app up in the debugger. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Sep 21 02:45:07 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 21 Sep 2006 10:45:07 +0200 Subject: [Rxtx] RTS control in RXTX In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> At 06:04 21/09/2006, Trent Jarvi wrote: >On Wed, 20 Sep 2006, Pete Flugstad wrote: > >> It is possible to work through much of this. There are folks looking at > >> an API update [under NDA now?]. > > > > Do you mean that there are people doing this (and they're under NDA), or > > are you asking the question? If you're asking the question; I > have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. Any chance one could get into this group? We can sign an NDA. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From ejy at SummitBid.com Thu Sep 21 05:20:43 2006 From: ejy at SummitBid.com (Ed Young) Date: Thu, 21 Sep 2006 05:20:43 -0600 Subject: [Rxtx] Parallel port access as non root user? Message-ID: I'm doing some preliminary testing to figure out how I can control the parallel port with RxTx. Basically, I'm trying to access the parallel port (/dev/lp0) from a non root process. Basically I have a program that can only access the port if it runs as root. Here's what happens when I run as root: root at falcon:~/src/k74- 1.0# ./pprxtx all set root at falcon:~/src/k74-1.0# ./pprxtx read 255 root at falcon:~/src/k74-1.0# ./pprxtx all clear root at falcon:~/src/k74-1.0# ./pprxtx read 0 Here's what happens when I run as a non root user (ed): ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Permission denied ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Permission denied /dev/lp0 I thought that all I had to do was to add my non rootport user to the device group (lp) in /etc/group and then that user would have permissions to read and write to that device. lp:x:7:cupsys, ed I also changed the device permissions to /dev: crw-rw-rw- 1 root lp 6, 0 2006-09-21 04:56 lp0 I still can't access the port unless I run as root. If I change the /dev/port (dangerously insecure) permissions to /dev: crw-rw-rw- 1 root kmem 1, 4 2006-09-21 04:56 port I then get: ed at falcon:~/src/k74-1.0$ ./pprxtx read /dev/port: Operation not permitted ed at falcon:~/src/k74-1.0$ ./pprxtx all set /dev/port: Operation not permitted Any ideas? I've done a fair amount of googling this and it seems like I'm doing everything correctly. Thanks, -- Ed -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060921/9e75c101/attachment-0015.html From smontgomery at mediaspansoftware.com Thu Sep 21 05:57:23 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 07:57:23 -0400 Subject: [Rxtx] 2.0.7 Universal Binary on Intel Mac crashing on port close? In-Reply-To: <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> References: <7588DCEF-2297-43A0-8797-D6D70A2210BE@mediaspansoftware.com> <9081A030-D55B-4D06-8085-BD8572F3CFA6@buechse.de> Message-ID: <9391A2C3-B44A-4589-AABE-6B24DD99A59F@mediaspansoftware.com> Thanks for the info, Joachim. I'll look for the Bugzilla entry and add comments if I can come up with a simple case to reproduce it. Interesting that you've seen it on PPC, I've never seen it myself there. First time for everything! - Sean On Sep 21, 2006, at 4:31 AM, Joachim Buechse wrote: > I have seen the same kind of crashes as well, albeit on PPC. > > This is due to the fact, that the event_info_struct gets damaged > during the closing of the port. Which leads to the fact that the > closing flag gets overwritten by some weird value, which again leads > to the call to pthread_cancel (normally this should never be called). > > I have posted this some weeks ago, but nobody was able to reproduce > it. I think I also filed in on Bugzilla. > > Best regard, > Joachim > > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 20.09.2006, at 21:18, Sean Montgomery wrote: > >> I've looked through the mailing list to see if something like this >> has already been discussed, but I didn't notice anything. Perhaps >> somebody might have seen something similar. >> >> I've got RXTX 2.0.7 final Universal Binary installed on an Intel >> single core Mac mini running OS X 10.4.6. There's a Keyspan USA28X >> serial adapter attached and Keyspan's 2.2 drivers are loaded (that's >> their latest Universal Binary drivers). >> >> I'm running a Java app using Java 1.4.2 that opens one of the Keyspan >> serial ports at 9600 baud, 8 data, 1 stop, no parity, RTS/CTS >> flowcontrol. I also call enableReceiveTimout(500) so that reads >> won't block forever. I don't write to the port, I only read. >> >> This works fine on all other machines I've tested, PPC and Intel. On >> this particular box when we attempt to close the serial port the JVM >> crashes. Here's the appropriate bit of the stack trace: >> >> Thread 17 Crashed: >> 0 libSystem.B.dylib 0x9005b9a4 pthread_cancel + 6 >> 1 librxtxSerial.jnilib 0x05fdd18f >> Java_gnu_io_RXTXPort_interruptEventLoop + 293 >> 2 <<00000000>> 0x03f36c4b 0 + 66284619 >> 3 <<00000000>> 0x03f31bc3 0 + 66264003 >> 4 <<00000000>> 0x03f31bc3 0 + 66264003 >> 5 <<00000000>> 0x03f31bc3 0 + 66264003 >> 6 <<00000000>> 0x03f31bc3 0 + 66264003 >> 7 <<00000000>> 0x03f31bc3 0 + 66264003 >> 8 <<00000000>> 0x03f2f0ed 0 + 66253037 >> 9 libclient.dylib 0x9562e6cc jio_snprintf + 250442 >> 10 libclient.dylib 0x95635e7e JVM_StartThread + 2424 >> 11 libclient.dylib 0x95635d81 JVM_StartThread + 2171 >> 12 libclient.dylib 0x95635cd1 JVM_StartThread + 1995 >> 13 libclient.dylib 0x95635bc4 JVM_StartThread + 1726 >> 14 libclient.dylib 0x955e7ea3 JNI_CreateJavaVM_Impl + >> 34773 >> 15 libSystem.B.dylib 0x90024a27 _pthread_body + 84 >> >> So it looks like a 2.0.7 Universal Library on Intel issue. If >> anybody has any ideas or if closing ports, interrupt event loops and >> crashes ring any bells, please let me know :-) >> >> Thanks, >> >> Sean >> >> P.S. The machine in question is several time zones away so I haven't >> been able to fire the app up in the debugger. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Sep 21 07:29:14 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 07:29:14 -0600 (MDT) Subject: [Rxtx] RTS control in RXTX In-Reply-To: <7.0.1.0.0.20060921104440.03781ed8@sms.nl> References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> <7.0.1.0.0.20060921104440.03781ed8@sms.nl> Message-ID: On Thu, 21 Sep 2006, Guillermo Rodriguez Garcia wrote: > At 06:04 21/09/2006, Trent Jarvi wrote: >> On Wed, 20 Sep 2006, Pete Flugstad wrote: >>>> It is possible to work through much of this. There are folks looking at >>>> an API update [under NDA now?]. >>> >>> Do you mean that there are people doing this (and they're under NDA), or >>> are you asking the question? If you're asking the question; I >> have no idea. >> >> Hi Pete >> >> We [rxtx] expressed interest in working towards a JSR. Doug mentioned >> that he would take a look and later mentioned in email that there is an >> NDA. > > Any chance one could get into this group? We can sign an NDA. Hi Guillermo I assume the process is open. I personally did not look into joining as I was still going through legal processes at work. Perhaps Doug has more information. Or maybe the process isn't moving at this time. Even a simple NDA is a big deal (timeline wise) for me to get an OK for so I have not bothered looking at all. -- Trent Jarvi tjarvi at qbang.org From smontgomery at mediaspansoftware.com Thu Sep 21 08:18:30 2006 From: smontgomery at mediaspansoftware.com (Sean Montgomery) Date: Thu, 21 Sep 2006 10:18:30 -0400 Subject: [Rxtx] RXTX cvs access? In-Reply-To: References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> Message-ID: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> I just tried to access cvs again using the instructions at http:// users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: cvs [login aborted]: connect to cvs.milestonesolutions.com (208.2.190.117):2401 failed: Connection refused after entering the password. Has anybody successfully accessed cvs since the server came back up? I'm wondering if the password might have changed... On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > > I did get an email back from Ken. Hementionedproblemswith the NOC > and said it should be back up this weekend. > > I'd just give you what I have on my laptop for 2.0 but I'd rather > wait. I > may have messed with the code since commiting to CVS. > > We need to tag the code for 2.0 and change the version number but what > is in CVS should be up to date. If someone wants to work with me this > weekend and build the Mac OS X version, we can release it on the rxtx > download page. > > I expect to be building Mac OS X this fall also but don't have that > setup > yet. > > > On Thu, 14 Sep 2006, Sean Montgomery wrote: > >> Uh, just tried to access cvs again just now, still timing out at cvs >> login... >> >> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >> X) support. Any suggestions on where I can access the binaries and/ >> or source? I'm hoping I'm just being stupid and missing the obvious >> here... please feel free to educate me :-P >> >> Thanks again, >> >> Sean >> >> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >> >>> Ok, so it's not just me ;-) >>> >>> Looks like it's still down right now. May I make a small appeal to >>> the Mac RXTX community, if anybody has a set of Universal Binary >>> RXTX >>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>> ftp site at qbang? >>> >>> Since the only thing I guess I'd actually need would be a UB >>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>> copy? >>> >>> Thanks, and my apologies for the "gimme", >>> >>> Sean >>> >>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>> >>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>> >>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>> (OS X >>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>> >>>>> http://www.rxtx.org/cvs.html >>>>> >>>>> Followed to the letter (including the rodent-oriented >>>>> password). It >>>>> appears that I can reach the server since I get a password request >>>>> but once I enter the password nothing happens for a while, then I >>>>> get: >>>>> >>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>> (208.2.190.117):2401 failed: Operation timed out >>>>> >>>>> Has anybody been able to access cvs lately? Do I need to know >>>>> some >>>>> special handshake or something ;-) >>>>> >>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>> best I >>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>> I'm >>>>> trying to get to the source via cvs. >>>> >>>> Hi Sean >>>> >>>> It looks like Ken is having some problems with his server. It >>>> can't have >>>> been down long. Lets let him have some time to get it back up. >>>> I'd email >>>> him but it goes to the same IP which is not working at the moment. >>>> >>>> -- >>>> Trent Jarvi >>>> tjarvi at qbang.org >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Sep 21 08:48:41 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 21 Sep 2006 10:48:41 -0400 Subject: [Rxtx] JCP - Status Report 1.0 In-Reply-To: References: <84d4a6d50609190910y14c54270g84cd1777eab1dac3@mail.gmail.com> <45120AB0.2040508@gmail.com> Message-ID: Hi All, I have signed a JSR to work with Sun on a javax.comm specification. This is a standard part of the JCP and this process is documented at: http://jcp.org/en/home/index You may want to take a look at the JCP FAQ (http://jcp.org/en/introduction/faq#2.5) for details on the differences between the agreement I signed and other JSPA versions. There are only 14 days between initiation and vote. This means, I think, that we need a nailed down initiation before we submit it, as there will be a small window of time before the vote occurs (I am a newbie to the process, so I could be wrong about this). The time-line is thick with milestones, and I would think that a reference implementation is good to have in hand before getting too deep into the process. Please correct me if I have this wrong. Thanks! - Doug >On Wed, 20 Sep 2006, Pete Flugstad wrote: >>> It is possible to work through much of this. There are folks looking at >>> an API update [under NDA now?]. >> >> Do you mean that there are people doing this (and they're under NDA), or >> are you asking the question? If you're asking the question; I have no idea. > >Hi Pete > >We [rxtx] expressed interest in working towards a JSR. Doug mentioned >that he would take a look and later mentioned in email that there is an >NDA. > >Thats all I know at this time. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From TEIXOEIRA at terra.es Thu Sep 21 11:08:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Thu, 21 Sep 2006 19:08:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <23095330.1158858481214.JavaMail.root@cps1> Hi, there. I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using HiperTerminal though. Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? Kind regards. java.io.IOException: Underlying input stream returned zero bytes at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Thu Sep 21 18:35:12 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:35:12 -0600 (MDT) Subject: [Rxtx] RXTX cvs access? In-Reply-To: <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> References: <6E74D8EB-4A25-4D92-ABEC-97D026486327@mediaspansoftware.com> <262364F1-CDA9-48FC-BBAD-28B04D53306D@mediaspansoftware.com> Message-ID: Hi Sean The cvs server needs to be started. I'll ask Ken. > telnet cvs.milestonesolutions.com 2401 Trying 208.2.190.117... telnet: connect to address 208.2.190.117: Connection refused On Thu, 21 Sep 2006, Sean Montgomery wrote: > I just tried to access cvs again using the instructions at http:// > users.frii.com/jarvi/rxtx/cvs.html but instead of timing out I get: > > cvs [login aborted]: connect to cvs.milestonesolutions.com > (208.2.190.117):2401 failed: Connection refused > > after entering the password. > > Has anybody successfully accessed cvs since the server came back up? > I'm wondering if the password might have changed... > > On Sep 14, 2006, at 11:08 PM, Trent Jarvi wrote: > >> >> I did get an email back from Ken. Hementionedproblemswith the NOC >> and said it should be back up this weekend. >> >> I'd just give you what I have on my laptop for 2.0 but I'd rather >> wait. I >> may have messed with the code since commiting to CVS. >> >> We need to tag the code for 2.0 and change the version number but what >> is in CVS should be up to date. If someone wants to work with me this >> weekend and build the Mac OS X version, we can release it on the rxtx >> download page. >> >> I expect to be building Mac OS X this fall also but don't have that >> setup >> yet. >> >> >> On Thu, 14 Sep 2006, Sean Montgomery wrote: >> >>> Uh, just tried to access cvs again just now, still timing out at cvs >>> login... >>> >>> I've got an unexpected need for RXTX 2.0.x Universal Binary (Mac OS >>> X) support. Any suggestions on where I can access the binaries and/ >>> or source? I'm hoping I'm just being stupid and missing the obvious >>> here... please feel free to educate me :-P >>> >>> Thanks again, >>> >>> Sean >>> >>> On Sep 13, 2006, at 1:09 PM, Sean Montgomery wrote: >>> >>>> Ok, so it's not just me ;-) >>>> >>>> Looks like it's still down right now. May I make a small appeal to >>>> the Mac RXTX community, if anybody has a set of Universal Binary >>>> RXTX >>>> 2.0.7/.8 installables that they post it to the Wiki or put it on the >>>> ftp site at qbang? >>>> >>>> Since the only thing I guess I'd actually need would be a UB >>>> librxtxSerial.jnilib maybe somebody could just zip it and mail me a >>>> copy? >>>> >>>> Thanks, and my apologies for the "gimme", >>>> >>>> Sean >>>> >>>> On Sep 12, 2006, at 9:04 PM, Trent Jarvi wrote: >>>> >>>>> On Tue, 12 Sep 2006, Sean Montgomery wrote: >>>>> >>>>>> I was just trying to access the RXTX source via cvs on my Mac >>>>>> (OS X >>>>>> 10.4.7, via the Bash shell in Terminal) using the instructions at: >>>>>> >>>>>> http://www.rxtx.org/cvs.html >>>>>> >>>>>> Followed to the letter (including the rodent-oriented >>>>>> password). It >>>>>> appears that I can reach the server since I get a password request >>>>>> but once I enter the password nothing happens for a while, then I >>>>>> get: >>>>>> >>>>>> cvs [login aborted]: connect to cvs.milestonesolutions.com >>>>>> (208.2.190.117):2401 failed: Operation timed out >>>>>> >>>>>> Has anybody been able to access cvs lately? Do I need to know >>>>>> some >>>>>> special handshake or something ;-) >>>>>> >>>>>> I'm trying to get ahold of the 2.0.7 release for OS X (or later, >>>>>> whatever will let me build 2.0.x Universal Binaries) but the >>>>>> best I >>>>>> can find is 2.0-7pre1 at ftp://ftp.qbang.org/pub/rxtx... hence >>>>>> I'm >>>>>> trying to get to the source via cvs. >>>>> >>>>> Hi Sean >>>>> >>>>> It looks like Ken is having some problems with his server. It >>>>> can't have >>>>> been down long. Lets let him have some time to get it back up. >>>>> I'd email >>>>> him but it goes to the same IP which is not working at the moment. >>>>> >>>>> -- >>>>> Trent Jarvi >>>>> tjarvi at qbang.org >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Thu Sep 21 18:45:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 21 Sep 2006 18:45:23 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <23095330.1158858481214.JavaMail.root@cps1> References: <23095330.1158858481214.JavaMail.root@cps1> Message-ID: On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org From TEIXOEIRA at terra.es Fri Sep 22 02:34:01 2006 From: TEIXOEIRA at terra.es (TEIXOEIRA@terra.es) Date: Fri, 22 Sep 2006 10:34:01 +0200 (MEST) Subject: [Rxtx] Underlying input stream returned zero bytes Message-ID: <1989016.1158914041928.JavaMail.root@cps2> Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. One more question. Does setting timeout/threshold before or after getting the input stream make a difference? Again, thanks. ----Mensaje original---- De: tjarvi at qbang.org Recibido: 22/09/2006 2:45 Para: , "RXTX Developers and Users" Asunto: Re: [Rxtx] Underlying input stream returned zero bytes On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > > Hi, there. > I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using > HiperTerminal though. > Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? > > Kind regards. > > java.io.IOException: Underlying input stream returned zero bytes > at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) > at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) > at java.io.InputStreamReader.read(InputStreamReader.java:167) > at java.io.BufferedReader.fill(BufferedReader.java:136) > at java.io.BufferedReader.readLine(BufferedReader.java:299) > at java.io.BufferedReader.readLine(BufferedReader.java:362) > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > Hello, It is perfectly normal for rxtx to return zero bytes depending upon how the timeout and threshold are set. If you do not want the read to timeout, set it to zero. *timeout threshold Behavior *------------------------------------------------------------------------ *0 0 blocks until 1 byte is available timeout > 0, * threshold = 0, blocks until timeout occurs, returns -1 * on timeout *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude * of threshold doesn't play a role. *0 >0 Blocks until 1 byte, magnitude of threshold doesn't * play a role I do not think defaults are documented so do not assume that they are the same between rxtx and sun. -- Trent Jarvi tjarvi at qbang.org Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From tjarvi at qbang.org Fri Sep 22 07:09:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 22 Sep 2006 07:09:53 -0600 (MDT) Subject: [Rxtx] Underlying input stream returned zero bytes In-Reply-To: <1989016.1158914041928.JavaMail.root@cps2> References: <1989016.1158914041928.JavaMail.root@cps2> Message-ID: It should not make a difference. On Fri, 22 Sep 2006, TEIXOEIRA at terra.es wrote: > > Many thanks, Trent. I wouldn't be able to find out about this behaviour unless, perhaps, reading rxtx sources. > One more question. Does setting timeout/threshold before or after getting the input stream make a difference? > > Again, thanks. > > > ----Mensaje original---- > De: tjarvi at qbang.org > Recibido: 22/09/2006 2:45 > Para: , "RXTX Developers and Users" > Asunto: Re: [Rxtx] Underlying input stream returned zero bytes > > On Thu, 21 Sep 2006, TEIXOEIRA at terra.es wrote: > >> >> Hi, there. >> I'm having difficulties reading a serial line with RXTX 2.1-7 on Windows XP, I can communicate through this serial line using >> HiperTerminal though. >> Also, I can't find any clues about this issue on the internet. Can anybody tell what might cause this exception while reading? >> >> Kind regards. >> >> java.io.IOException: Underlying input stream returned zero bytes >> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:415) >> at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at java.io.BufferedReader.fill(BufferedReader.java:136) >> at java.io.BufferedReader.readLine(BufferedReader.java:299) >> at java.io.BufferedReader.readLine(BufferedReader.java:362) >> >> >> >> Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. >> >> > > Hello, > > It is perfectly normal for rxtx to return zero bytes depending upon how > the timeout and threshold are set. If you do not want the read to > timeout, set it to zero. > > > *timeout threshold Behavior > *------------------------------------------------------------------------ > *0 0 blocks until 1 byte is available timeout > 0, > * threshold = 0, blocks until timeout occurs, returns -1 > * on timeout > *>0 >0 blocks until timeout, returns - 1 on timeout, magnitude > * of threshold doesn't play a role. > *0 >0 Blocks until 1 byte, magnitude of threshold doesn't > * play a role > > I do not think defaults are documented so do not assume that they are the > same between rxtx and sun. > > -- > Trent Jarvi > tjarvi at qbang.org > > > > > Prueba el correo Terra ( http://www.terra.es/correo ); Seguro, r?pido, fiable. > > From knute at frazmtn.com Sat Sep 23 14:04:01 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 13:04:01 -0700 Subject: [Rxtx] read() not blocking? Message-ID: <451530C1.24106.F185E5@knute.frazmtn.com> I'm converting from javax.comm to rxtx and have run in to a snag. My code needs to block indefinitely on a serial port read() but is returning -1. Both read timeout and read threshold are disabled. It doesn't seem to matter if I call disableReceiveTimeout() or enableReceiveTimeout(0). Behavior appears normal if timeout is set to some normal value. For now I have enabled receive timeout and set the value to Integer.MAX_VALUE. Is this a bug or? My computer is running XP SP2 and RXTX is 2.1-7. Any ideas would be greatly appreciated. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Sat Sep 23 18:29:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 23 Sep 2006 18:29:06 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <451530C1.24106.F185E5@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > I'm converting from javax.comm to rxtx and have run in to a snag. My > code needs to block indefinitely on a serial port read() but is > returning -1. Both read timeout and read threshold are disabled. It > doesn't seem to matter if I call disableReceiveTimeout() or > enableReceiveTimeout(0). Behavior appears normal if timeout is set > to some normal value. For now I have enabled receive timeout and set > the value to Integer.MAX_VALUE. > > Is this a bug or? > > My computer is running XP SP2 and RXTX is 2.1-7. > > Any ideas would be greatly appreciated. > > Thanks, > > Hi Knute I would expect that to work. Is your serial port unusual? Perhaps multiport or a USB dongle? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sat Sep 23 18:58:43 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 17:58:43 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, Message-ID: <451575D3.2908.5C1A6E@knute.frazmtn.com> >On Sat, 23 Sep 2006, Knute Johnson wrote: > >> I'm converting from javax.comm to rxtx and have run in to a snag. My >> code needs to block indefinitely on a serial port read() but is >> returning -1. Both read timeout and read threshold are disabled. It >> doesn't seem to matter if I call disableReceiveTimeout() or >> enableReceiveTimeout(0). Behavior appears normal if timeout is set >> to some normal value. For now I have enabled receive timeout and set >> the value to Integer.MAX_VALUE. >> >> Is this a bug or? >> >> My computer is running XP SP2 and RXTX is 2.1-7. >> >> Any ideas would be greatly appreciated. >> >> Thanks, >> >> > >Hi Knute > >I would expect that to work. Is your serial port unusual? Perhaps >multiport or a USB dongle? > No it is the built-in port on my Dell 380. Nothing unusual about it. I did another experiment and found that even with the Integer.MAX_VALUE timeout, about every minute and 20 seconds the read() returned a -1. There is something funny here. Anything you want me to try? Thanks, -- Knute Johnson Molon Labe... From knute at frazmtn.com Sat Sep 23 19:47:00 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sat, 23 Sep 2006 18:47:00 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: <451575D3.2908.5C1A6E@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> Message-ID: <45158124.24690.21CDFD@knute.frazmtn.com> Here is my test program and the output. I've tried it on my Dell 380 desktop and my old Dell laptop and the results are the same. import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); sp.enableReceiveTimeout(Integer.MAX_VALUE); InputStream is = sp.getInputStream(); BufferedInputStream bis = new BufferedInputStream(is); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = bis.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Started 18:40:11 18:40:51 -1 18:41:31 -1 18:42:11 -1 18:42:51 -1 18:43:31 -1 Thanks, -- Knute Johnson Molon Labe... From lyon at docjava.com Sun Sep 24 07:55:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 24 Sep 2006 09:55:25 -0400 Subject: [Rxtx] port in use exception Message-ID: Hi All, For the longest time, I was using RXTX to dial the phone. Recently, I switched to the PortIO device (USB to Serial converter). If I quit from the application and restart, I get an exception, as seen below, on the Mac. However, trying again seems to work fine. As long as the application remains open, everything works well. I do close the port when I am done. Hmm. I am using a odd-ball version of RXTX, as you can see. This could be the culprit. Any ideas? Thanks! - Doug Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock trying to open:/dev/tty.usbserial gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) at serialPort.Utils.init(Utils.java:62) at serialPort.Utils.(Utils.java:37) at serialPort.Utils.getSerialPortUtils(Utils.java:101) at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) at gui.run.RunButton.actionPerformed(RunButton.java:45) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) at java.awt.Component.processMouseEvent(Component.java:5554) at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) at java.awt.Component.processEvent(Component.java:5319) at java.awt.Container.processEvent(Container.java:2010) at java.awt.Component.dispatchEventImpl(Component.java:4021) at java.awt.Container.dispatchEventImpl(Container.java:2068) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) at java.awt.Container.dispatchEventImpl(Container.java:2054) at java.awt.Window.dispatchEventImpl(Window.java:1774) at java.awt.Component.dispatchEvent(Component.java:3869) at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) From tjarvi at qbang.org Sun Sep 24 08:40:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 24 Sep 2006 08:40:16 -0600 (MDT) Subject: [Rxtx] read() not blocking? In-Reply-To: <45158124.24690.21CDFD@knute.frazmtn.com> References: <451530C1.24106.F185E5@knute.frazmtn.com>, , <451575D3.2908.5C1A6E@knute.frazmtn.com> <45158124.24690.21CDFD@knute.frazmtn.com> Message-ID: On Sat, 23 Sep 2006, Knute Johnson wrote: > Here is my test program and the output. I've tried it on my Dell 380 > desktop and my old Dell laptop and the results are the same. > > import java.io.*; > import java.text.*; > import java.util.*; > import gnu.io.*; > > public class test { > public static void main(String[] args) throws Exception { > > CommPortIdentifier cpi = > CommPortIdentifier.getPortIdentifier("COM1"); > SerialPort sp = (SerialPort)cpi.open("test",2500); > > // set serial port parameters > sp.setSerialPortParams(9600,SerialPort.DATABITS_8, > SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); > sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); > > sp.enableReceiveTimeout(Integer.MAX_VALUE); > > InputStream is = sp.getInputStream(); > BufferedInputStream bis = new BufferedInputStream(is); > > SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); > > System.out.println("Started "+sdf.format(new Date())); > > while (true) { > int n = bis.read(); > System.out.println(sdf.format(new Date())+" "+n); > } > } > } > > C:\com\knutejohnson\redrock\race>java test > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Started 18:40:11 > 18:40:51 -1 > 18:41:31 -1 > 18:42:11 -1 > 18:42:51 -1 > 18:43:31 -1 > > Thanks, > > Hi Knute I can try this after work tomorrow. You just assume the threshold is a value you want? -- Trent Jarvi tjarvi at qbang.org From knute at frazmtn.com Sun Sep 24 13:26:19 2006 From: knute at frazmtn.com (Knute Johnson) Date: Sun, 24 Sep 2006 12:26:19 -0700 Subject: [Rxtx] read() not blocking? In-Reply-To: References: <451530C1.24106.F185E5@knute.frazmtn.com>, <45158124.24690.21CDFD@knute.frazmtn.com>, Message-ID: <4516796B.14342.84C784@knute.frazmtn.com> So I've redone my tests and specifically set the receive timeout and receive threshold states. receiveTimeoutDisabled() and receiveThresholdDisabled() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.disableReceiveTimeout(); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: false Started 12:06:48 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 12:06:48 -1 Note that it returns very quickly from the read, many times per second. This should block yes? Next is: enableReceiveTimeout(Integer.MAX_VALUE) disableReceiveThreshold() import java.io.*; import java.text.*; import java.util.*; import gnu.io.*; //import javax.comm.*; public class test { public static void main(String[] args) throws Exception { CommPortIdentifier cpi = CommPortIdentifier.getPortIdentifier("COM1"); SerialPort sp = (SerialPort)cpi.open("test",2500); // set serial port parameters sp.setSerialPortParams(9600,SerialPort.DATABITS_8, SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); sp.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); // both receive timeout and receive threshold disabled sp.enableReceiveTimeout(Integer.MAX_VALUE); sp.disableReceiveThreshold(); System.out.println("isReceiveThresholdEnabled: " + sp.isReceiveThresholdEnabled()); System.out.println("isReceiveTimeoutEnabled: " + sp.isReceiveTimeoutEnabled()); InputStream is = sp.getInputStream(); SimpleDateFormat sdf = new SimpleDateFormat("HH:mm:ss"); System.out.println("Started "+sdf.format(new Date())); while (true) { int n = is.read(); System.out.println(sdf.format(new Date())+" "+n); } } } C:\com\knutejohnson\redrock\race>java test Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 isReceiveThresholdEnabled: false isReceiveTimeoutEnabled: true Started 12:09:11 12:09:51 -1 12:10:31 -1 12:11:11 -1 12:11:51 -1 12:12:32 -1 12:13:12 -1 Note the approximately 40 second timeout when Integer.MAX_VALUE should yield about 562 hours. I did just find something interesting, a timeout setting of 65535 gave a 1:26 timeout. I'm trying 3,600,000 now to see if it will be close to an hour. Any suggestions of what to try next would be great. Thanks, -- Knute Johnson Molon Labe... From tjarvi at qbang.org Mon Sep 25 00:14:35 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 00:14:35 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > Hi All, > For the longest time, I was using RXTX to dial the phone. > Recently, I switched to the PortIO device (USB to Serial converter). > > If I quit from the application and restart, I get an exception, as seen > below, on the Mac. However, trying again seems to work fine. > As long as the application remains open, everything works well. > > I do close the port when I am done. > Hmm. I am using a odd-ball version of RXTX, as you can see. > This could be the culprit. Any ideas? > Thanks! > - Doug > > Native lib Version = R-testing-XTX-2.1-7pre20noLock > Java lib Version = R-testing-XTX-2.1-7pre20noLock > trying to open:/dev/tty.usbserial > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) > at serialPort.Utils.init(Utils.java:62) > at serialPort.Utils.(Utils.java:37) > at serialPort.Utils.getSerialPortUtils(Utils.java:101) > at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) > at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) > at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) > at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) > at gui.run.RunButton.actionPerformed(RunButton.java:45) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) > at java.awt.Component.processMouseEvent(Component.java:5554) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) > at java.awt.Component.processEvent(Component.java:5319) > at java.awt.Container.processEvent(Container.java:2010) > at java.awt.Component.dispatchEventImpl(Component.java:4021) > at java.awt.Container.dispatchEventImpl(Container.java:2068) > at java.awt.Component.dispatchEvent(Component.java:3869) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) > at java.awt.Container.dispatchEventImpl(Container.java:2054) > at java.awt.Window.dispatchEventImpl(Window.java:1774) > at java.awt.Component.dispatchEvent(Component.java:3869) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) hehe.. I remember making that oddball version for you :) Its not very different from like releases at the time. Perhaps you are trying to open the port before the kernel is ready? Are you opening right after closing? The more recent versions of rxtx may close the port faster which could make a difference depending how you are using threads. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Mon Sep 25 03:52:50 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 25 Sep 2006 05:52:50 -0400 Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: Hi All, I have created a web-start testing facility to try an help with the duplication of the bug that I am seeing with the PortIO device. The web start console reports: ---------------------------------------------------- Devel Library ========================================= Native lib Version = R-testing-XTX-2.1-7pre20noLock Java lib Version = R-testing-XTX-2.1-7pre20noLock port already in use The application may be run from: http://show.docjava.com:8086/book/cgij/code/jnlp/serialPort.SimpleWriteRead.jnlp public static void main(String[] args) { CommPortUtils cpu = CommPortUtils.getCommPortUtils(); portIdInterface = cpu.getACommPortFromUser(); // SETUP SERIAL PORT: try { serialPortInterface = (SerialPortInterface) portIdInterface.open("SimpleWriteRead", 1000); } catch (PortInUseException e) { System.out.println("port already in use"); return; } Trent: You asked: >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are using threads. I am not sure if I have answered your question. The program, produced the above output after an overnight wait. How can I tell if the kernel is ready? Thanks! - Doug >On Sun, 24 Sep 2006, Dr. Douglas Lyon wrote: > >> Hi All, >> For the longest time, I was using RXTX to dial the phone. >> Recently, I switched to the PortIO device (USB to Serial converter). >> >> If I quit from the application and restart, I get an exception, as seen >> below, on the Mac. However, trying again seems to work fine. >> As long as the application remains open, everything works well. >> >> I do close the port when I am done. >> Hmm. I am using a odd-ball version of RXTX, as you can see. >> This could be the culprit. Any ideas? >> Thanks! >> - Doug >> >> Native lib Version = R-testing-XTX-2.1-7pre20noLock >> Java lib Version = R-testing-XTX-2.1-7pre20noLock >> trying to open:/dev/tty.usbserial >> gnu.io.PortInUseException: Unknown Application >> at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:335) >> at serialPort.Utils.init(Utils.java:62) >> at serialPort.Utils.(Utils.java:37) >> at serialPort.Utils.getSerialPortUtils(Utils.java:101) >> at gui.touchtone.DialUtils.doModemDial(DialUtils.java:70) >> at addbk.JAddressBook.ViewPanel.dial(ViewPanel.java:141) >> at addbk.JAddressBook.ViewPanel.access$300(ViewPanel.java:20) >> at addbk.JAddressBook.ViewPanel$11.run(ViewPanel.java:127) >> at gui.run.RunButton.actionPerformed(RunButton.java:45) >> at >> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1882) >> at >> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2202) >> at >> >>javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420) >> at >> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258) >> at >> >>javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:234) >> at >> java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:231) >> at java.awt.Component.processMouseEvent(Component.java:5554) >> at javax.swing.JComponent.processMouseEvent(JComponent.java:3126) >> at java.awt.Component.processEvent(Component.java:5319) >> at java.awt.Container.processEvent(Container.java:2010) >> at java.awt.Component.dispatchEventImpl(Component.java:4021) >> at java.awt.Container.dispatchEventImpl(Container.java:2068) >> at java.awt.Component.dispatchEvent(Component.java:3869) >> at >> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4256) >> at >> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3936) >> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3866) >> at java.awt.Container.dispatchEventImpl(Container.java:2054) >> at java.awt.Window.dispatchEventImpl(Window.java:1774) >> at java.awt.Component.dispatchEvent(Component.java:3869) > > at java.awt.EventQueue.dispatchEvent(EventQueue.java:463) >> at >> >>java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269) >> at >> >>java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184) >> at >> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:110) > > >hehe.. I remember making that oddball version for you :) Its not very >different from like releases at the time. > >Perhaps you are trying to open the port before the kernel is ready? Are >you opening right after closing? The more recent versions of rxtx may >close the port faster which could make a difference depending how you are >using threads. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Sep 25 04:22:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 25 Sep 2006 04:22:16 -0600 (MDT) Subject: [Rxtx] port in use exception In-Reply-To: References: Message-ID: On Mon, 25 Sep 2006, Dr. Douglas Lyon wrote: